Each class will be in a separate file (standard convention: x.e for the
file name if the class is called X).
Each cluster will be in a directory (folder) containing such class
files; subclusters are in subdirectories.
This document is a quick summary of Eiffel language mechanisms. It relies on the ECMA standard but indicates which constructs are not yet supported by current compilers.
The aim is not to provide a complete introduction to the language (for that, the best reference is the introduction to the ECMA standard), but to enable programmers familiar with other languages to see quickly what's original (and not) in Eiffel.
At the level above classes: there is a notion of "cluster". A cluster is essentially a group of classes, and possibly subclusters since clusters can be nested. But there is no language construct for "cluster"; this is an organizational tool left to the environment. Typically (but again this is not prescribed):
Each class will be in a separate file (standard convention: x.e for the
file name if the class is called X).
Each cluster will be in a directory (folder) containing such class
files; subclusters are in subdirectories.
At the level below classes: a class contains features (roughly corresponding to "members" in e.g. C++), a class invariant, and some other properties such as a "notes" section for documentation.
Any system must have a class designated as "root", and one of its creation procedures designated as "root procedure". Executing the system consists of creating an instance of the root class and executing its root procedure. (Of course this generally creates new objects, calls new features etc.)
Queries, which give information about an instance.
Commands, which modify an instance.
This distinction is important to the Eiffel method. In particular:
Uniform Access Principle: from the outside, whether a query is an
attribute (field in each object) or a function (algorithm) should not
make any difference. For example a_vehicle.speed could be an attribute,
accessed from the object's representation; or it could be computed by a
function that divides distance by time. The notation is the same in both
cases, so that it's easy to change representation without affecting the
rest of the software.
Command-Query Separation Principle:
Queries must not modify the instance. This is not a language rule but a
methodological principle. So in good Eiffel style one does not find
"get" function that change something and return a result; instead there
are commands (procedures) to change objects, and queries to obtain
information about the object, resulting from preceding changes.
An important property of Eiffel is that a class is fundamentally a mapping from feature names to features. More plainly said this means that one name, within one class, means one thing. This keeps things simple and in particular is what makes the multiple inheritance mechanism possible (see below).
Names can, of course, be reused in different classes, but in a given class if you need another feature you'll have to invent another name. This is really no limitation since the conventional kinds of overloading are, in an object-oriented perspective, applied to different classes. For example if you want to have several versions of "+":
a + b for a, b: INTEGER a + b for a, b: REAL a + b for a, b: VECTOR [INTEGER]
then in Eiffel it simply means that the three classes involved each have a feature
plus alias "+" (other: XXX): XXX
where XXX is the given class (INTEGER, REAL, VECTOR [G]). (See "Operator and bracket syntax, assigner commands" below.) All the usual forms of operator overloading are thus supported; in fact the mechanism (unlike in most languages) leaves considerable freedom in making up new operators, as may be needed in scientific and engineering applications. What is not possible is the kind of argument overloading where a given class has both a feature f (x: X) and another f (y: Y) with the same names. I have discussed [1] how such overloading is useless, damages readability, and complicates the language mechanism needlessly.
The concepts of Design by Contract are central to Eiffel. The mechanisms are tightly integrated with the language. The basic constructs are:
Routine precondition
Routine postcondition
Class invariant
In addition, the language supports a "Check instruction" (a kind of "assert") and, in the syntax for loops, clauses for a loop invariant and a loop variant.
As defined in the Design by Contract methodology, contracts guide redefinition of features in inheritance. Specifically, in a redefinition:
The precondition can only be weakened, to ensure that any call that met
the requirements of the original version still meets those of the
redefined one. The keyword in that case is no longer require
but require else.
The postcondition can only be strengthened, to ensure that any result
guaranteed by the original version is still provided by the redefined
one. The keyword in that case is no longer ensure
but ensure then.
class LIST [G] ...
G is known as a "formal generic parameter". (Eiffel reserves "argument" for routines, and uses "parameter" only for generic classes.) With such a declaration G represents within the class an arbitrary type; so a function can return a value of type G, and a routine can take an argument of that type:
item: G do ... end put (x: G) do ... end
The LIST [INTEGER] and LIST [WORD] are "generic derivations" of this class. Permitted combinations(with n: INTEGER, w: WORD, il: LIST [INTEGER], wl: LIST [WORD]) are
n := il.item wl.put (w)
INTEGER resp. WORD are the "actual generic parameters" in these generic derivations.
It is also possible to have constrained formal parameters, for which the actual parameter must inherit from a given class, the "constraint". For example in
class HASH_TABLE [G, KEY -> HASHABLE]
a derivation HASH_TABLE [INTEGER, STRING] is valid only if STRING inherits from HASHABLE (as it it indeed does in typical Eiffel libraries). Within the class, having KEY constrained by HASHABLE means that for x: KEY it is possible to apply to x all the features of HASHABLE, as in x.hash_code.
To inherit from one or more others, a class will include a inherit clause at the beginning:
class C inherit A B ... Rest of class declaration ...
The class may redefine (override) some or all of the inherited features. This must be explicitly announced at the beginning of the class through a redefine subclause of the inheritance clause, as in
class C inherit A redefine f, g, h end B redefine u, v end
Then the class will contain new declarations of the features listed, which locally override the inherited ones.
Such declarations would be invalid in the absence of a redefine subclause since the class would then violate the no-overloading principle. The subclause, of course, also helps for readability, by announcing at the top of a class what functionality it adapts from the given parent.
Eiffel fully applies dynamic binding: in a feature call x.f the version to be called is always the one applicable to the class of the object denoted by x at the time of execution. Eiffel has no "static binding", except as a compiler optimization. (In C++ terms: all functions þave the same semantics as if they had been declared "virtual"; finding out that a particular function doesn't need dynamic binding is the responsibility of the compiler, not the programmer.)
Inheritance normally allows polymorphism (and hence subtyping): if B inherits from if A, then x := y is legal for x of type x A and y of type B.
Sometimes inheritance is for reuse only and is not intended for polymorphism. In such cases the inherit clause should start with
inherit {NONE}
This facility is, however, not yet supported by current compilers.
If instead of ```class''', a class starts with ```deferred class''', it is not meant to have direct instances: an instruction ```create''' ``x...'', with ``x'' of the corresponding type, is invalid. Only "effective" (non-deferred) descendants of the class can be instantiated.
A feature can itself be declared ```deferred''; the ```deferred''' keyword replaces the ```do''' clause, so the feature has no implementation. As soon as a class has at least one deferred feature, it must itself be marked as deferred. The reverse is not true: one can mark a class deferred to prevent instantiation even if all its features are effective.
Deferred classes (also called abstract classes) are similar to the "interfaces" of languages like Java and C#, but with an important difference: there is no need for a deferred class to be all deferred. Partially deferred classes play an important role in the Eiffel method's "seamless development", which suggests a continuous development process. The first version of a class, at the analysis or design stage, can be fully deferred, and then follow a succession of continuous refinements through inheritance until it gets to a fully effective stage.
[To be completed.]
TUPLE [name: STRING; weight: REAL; date: DATE]
and could be use to describe a simple notion of birth record if a class is not needed. An instance of such a tuple is simply a sequence of values with the given types, given in brackets, such as
["Brigitte", 3.5, Last_night]
Components of such a tuple can be accessed as if the tuple tags were attributes of a class, for example if t] has been assigned the above tuple then t.weight] has value 3.5.
Thanks to the notion of assigner command (see below), dot notation can also be used to assign components of such a tuple, as in
t.weight := t.weight + 0.5
The tuple tags are optional, so that it is also possible to write a tuple type as TUPLE [STRING, REAL, DATE]. (In some compilers this is the only form of tuple, as tags were introduced with the ECMA standard.)
The precise specification of e.g. TUPLE [A, B, C] is that it describes sequences of at least three elements, the first three being of types A, B, C respectively. As a result TUPLE [A, B, C] conforms to (may be assigned to) TUPLE [A, B], to TUPLE [A] and to TUPLE (without parameters), the topmost tuple type to which all tuple types conform.
For example, to iterate a certain action over a list, it suffices to write
my_list.do_all (agent my_action)
or, if the action is to be executed only on elements satisfying a certain condition:
my_list.do_all (agent my_action, agent my_test)
In these examples, my_action and my_test are routines. Prefixing them with agent yields an object that represents the corresponding routine with all its properties, in particular the ability to be called with the appropriate arguments. So if a represents that object (for example because a is the argument to do_all), the instruction
a.call ([x])
will call the original routine with the argument x, as if we had directly called the original routine: my_action (x). Arguments to call are passed as a tuple, here [x].
It is possible to keep some arguments to an agent open and make others closed. The open arguments are passed as arguments to call: they are provided at the time of agent use. The closed arguments are provided at the time of agent definition. For example, if action2 has two arguments, the iteration
my_list.do_all (agent action2 (?, y)
iterates action2 (x, y) for successive values of x, where the second arguments remained set to y. The question mark ? indicates an open argument; y is a closed argument of the agent. Note that the basic syntax agent f is a shorthand for agent f (?, ?, ...) with all arguments open. It is also possible to make the target of an agent open through the notation {T}? where T is the type of the target.
The distinction between open and closed operands (operands = arguments + target) corresponds to the distinction between bound and free variables in lambda calculus. An agent expression such as action2 (?, y) with some operands closed and some open corresponds to a version of the original operation curried on the closed operands.
The agent mechanism has been recently generalized to allow defining an agent without reference to an existing routine (such as my_action, my_test, action2), through inline agents as in
my_list.do_all (agent (x: INTEGER) require positive: x > 0 do x := x – 1 ensure x = old x – 1 end )
The inline agent passed here can have all the trappings of a normal routine, including precondition, postcondition, rescue clause (not used here), and a full signature. This avoids defining routines when all that's needed is a computation to be wrapped in an agent. This is useful in particular for contracts, as in an invariant clause that expresses that all elements of a list are positive:
my_list.for_all (agent (x: INTEGER): BOOLEAN do Result := (x > 0) end)
The current agent mechanism leaves a possibility of run-time type error (if a routine with n arguments is passed to an agent expecting m arguments with m < n). This can be avoided by a run-time check through the precondition valid_arguments of call. Several proposals for a purely static correction of this problem are available, including a language change proposal by Ribet et al. [2].
"Once" functions serve in particular to provide shared objects; the first call will create the object, subsequent ones will return the reference to that object. The typical scheme is
shared_object: SOME_TYPE do create Result.make (args) -- This creates the object and returns a reference to it through Result end
While the reference remains the same, later calls of the form shared_object.do_something can change the content of the object.
"Once" procedures can take care of initialization: several clients of a certain libraries can include a call to the initialization procedure, but only the first such call to happen will actually have an effect. The goal is to achieve decentralized initialization, avoiding the need for an initialization module (which could damage the modular structure of the program).
The ECMA specification allows variants of "once" (qualified by a keyword in parentheses, e.g. once (THREAD): once per process, once per thread, once per object. This is not, however, fully implemented yet by current compilers (typically, only PROCESS and THREAD).
(Conversion principle) A type may not both conform and convert to another
For example NEWSPAPERmay conform to to PUBLICATION, but INTEGER converts to REAL (and does not inherit from it).
The conversion mechanism simply generalizes the ad hoc conversion rules (such as indeed between INTEGERand REAL) that exist in most programming languages, making them applicable to any type as long as the above principle is observed. For example a REAL class may be declared to convert to REAL; this makes it possible to create a string from a date simply through
my_string := my_date
as a shortcut for using an explicit object creation with a conversion procedure:
create my_string.make_from_date (my_date)
To make the first form possible as a synonym for the first, it suffices to list the creation procedure (constructor) make_from_date in a convert clause at the beginning of the class.
As another example, if there is such a conversion procedure listed from TUPLE [day: INTEGER; month: STRING; year: INTEGER]], then one can directly assign a tuple to a date, causing the appropriate conversion, as in
Bastille_day := [14, "July", 1789]
Eiffel's view of computation is completely object-oriented in the sense that every operation is relative to an object, the "target". So for example an addition
[1] a + b
is conceptually understood as if it were a function call
[2] a.plus (b)
[1] Overloading vs Object Technology, in Journal of Object-Oriented Programming (JOOP), vol. 14, no. 4, October-November 2001, available online.
[2] Ribet, Cyril Adrian, Olivier Zendra, Dominique Colnet: Conformance of agents in the Eiffel language, in JOT:
©2006, Bertrand Meyer (based on material from "Eiffel: The language"), © Bertrand Meyer, 1990.