Bertrand Meyer: Basic Eiffel language mechanisms </head>  <body> <h1>Basic Eiffel language mechanisms Bertrand Meyer, August 2006</h1> 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. <h2>Overall structure</h2> An Eiffel "system" (or "program") is a collection of classes. The class is the major unit of decomposition. 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): <ul> <img src="/~meyer/images/icons/greenball.gif" alt="+"> Each class will be in a separate file (standard convention: x.e for the file name if the class is called X). <img src="/~meyer/images/icons/greenball.gif" alt="+"> Each cluster will be in a directory (folder) containing such class files; subclusters are in subdirectories. </ul> 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.) <h2>Features, commands, queries</h2> The primary characteristic of a class is that it contains a set of features. As a class represents a set of run-time objects (its instances), a feature is an operation on these objects. Operations are of two kinds: <ul> <img src="/~meyer/images/icons/greenball.gif" alt="+"> Queries, which give information about an instance. <img src="/~meyer/images/icons/greenball.gif" alt="+"> Commands, which modify an instance. </ul> This distinction is important to the Eiffel method. In particular: <ul> <img src="/~meyer/images/icons/greenball.gif" alt="+"> 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. <img src="/~meyer/images/icons/greenball.gif" alt="+"> 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. </ul> <h2>Feature names and no-overloading</h2> 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 "+": <pre> a + b for a, b: INTEGER a + b for a, b: REAL a + b for a, b: VECTOR [INTEGER] </pre> then in Eiffel it simply means that the three classes involved each have a feature <pre> plus alias "+" (other: XXX): XXX </pre> 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. <h2>Design by Contract in Eiffel</h2> The concepts of Design by Contract are central to Eiffel. The mechanisms are tightly integrated with the language. The basic constructs are: <ul> <img src="/~meyer/images/icons/greenball.gif" alt="+"> Routine precondition <img src="/~meyer/images/icons/greenball.gif" alt="+"> Routine postcondition <img src="/~meyer/images/icons/greenball.gif" alt="+"> Class invariant </ul> 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: <ul> <img src="/~meyer/images/icons/greenball.gif" alt="+"> 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. <img src="/~meyer/images/icons/greenball.gif" alt="+"> 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. </ul> <h2>Genericity</h2> Classes can be generic, to express that they are parameterized by types. Generic parameters appear in square brackets: <pre> class LIST [G] ... </pre> 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: <pre> item: G do ... end put (x: G) do ... end </pre> 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 <pre> n := il.item wl.put (w) </pre> 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 <pre> class HASH_TABLE [G, KEY -> HASHABLE] </pre> 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. <h2>Inheritance basics</h2> To inherit from one or more others, a class will include a inherit clause at the beginning: <pre> class C inherit A B ... Rest of class declaration ... </pre> 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 <pre> class C inherit A redefine f, g, h end B redefine u, v end </pre> 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.) <h2>Non-conforming inheritance</h2> 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 <pre> inherit {NONE} </pre> This facility is, however, not yet supported by current compilers. <h2>Deferred classes</h2> 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. <h2>Multiple and repeated inheritance</h2> [To be completed.] <h2>Renaming</h2> A class that inherits from one or more others gets all its features, by default under their original names. It may, however, change their names through a rename clauses. This is required in the case of multiple inheritance if there are name clashes between inherited features; without renaming, the resulting class would violate the no-overloading principle noted above and hence would be invalid. <h2>Tuples</h2> Tuples types may be viewed as a simple form of class, providing only attributes and the corresponding "setter" procedure. A typical tuple type reads <pre> TUPLE [name: STRING; weight: REAL; date: DATE] </pre> 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 <pre> ["Brigitte", 3.5, Last_night] </pre> 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 <pre> t.weight := t.weight + 0.5 </pre> 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. <h2>Agents</h2> Eiffel provides an "agent" mechanism to wrap operations into objects. This is useful for iteration, event-driven programming, and other applications for which it is useful to pass operations around the program structure. Agents correspond to lambda calculus and to "closures"; they make it possible to combine the object-oriented paradigm with a significant set of mechanisms available in functional programming languages. For example, to iterate a certain action over a list, it suffices to write <pre> my_list.do_all (agent my_action) </pre> or, if the action is to be executed only on elements satisfying a certain condition: <pre> my_list.do_all (agent my_action, agent my_test) </pre> 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 <pre> a.call ([x]) </pre> 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 <pre> my_list.do_all (agent action2 (?, y) </pre> 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 <pre> my_list.do_all (agent (x: INTEGER) require positive: x > 0 do x := x – 1 ensure x = old x – 1 end ) </pre> 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: <pre> my_list.for_all (agent (x: INTEGER): BOOLEAN do Result := (x > 0) end) </pre> 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]. <h2>Once routines</h2> A routine can be declared "once" (with the keyword once replacing the more common do) to indicate that it will only be executed on the first call. Subsequent calls have no further effect; in the case of a function, they return the same value as the first, for example a reference to the same object. "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 <pre> shared_object: SOME_TYPE do create Result.make (args) -- This creates the object and returns a reference to it through Result end </pre> 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). <h2>Conversions</h2> Eiffel provides a mechanism to allow conversions between various types. The mechanisms coexists with inheritance and complements it. To avoid any confusion between the two mechanisms, the design enforces the following principle: (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 <pre> my_string := my_date </pre> as a shortcut for using an explicit object creation with a conversion procedure: <pre> create my_string.make_from_date (my_date) </pre> 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 <pre> Bastille_day := [14, "July", 1789] </pre> <h2>Exception handling</h2> [To be completed.] <h2>Operator and bracket syntax, assigner commands</h2> 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 <pre> [1] a + b </pre> is conceptually understood as if it were a function call <pre> [2] a.plus (b) </pre> <h2>References</h2> [Incomplete, others will be added.] [1] Overloading vs Object Technology, in Journal of Object-Oriented Programming (JOOP), vol. 14, no. 4, October-November 2001, available <a href="http://se.ethz.ch/~meyer/publications/joop/overloading.pdf ">online</a>. [2] Ribet, Cyril Adrian, Olivier Zendra, Dominique Colnet: Conformance of agents in the Eiffel language, in JOT: <I<Journal of Object Technology, vol. 3, no. 4, April 2004, Special issue: TOOLS USA 2003, pp. 125-143. Available on line from the <a href="http://www.jot.fm/issues/issue_2004_04/article7">JOT article page</a>. ©2006, Bertrand Meyer (based on material from "Eiffel: The language"), © Bertrand Meyer, 1990.  <center> <table border="0" cellspacing="0" cellpadding="0"><tr><td> <hr> <a href="http://www.inf.ethz.ch/~meyer">Meyer home</a> - <a href="http://www.inf.ethz.ch/~meyer/publications/">Publications</a> - <a href="http://www.inf.ethz.ch/~meyer/events/">Events</a> - <a href="http://se.inf.ethz.ch/">Chair of Software Engineering</a> - <a href="http://www.inf.ethz.ch/">CS Department</a> <hr> </td><td width="30%"> </td></tr></table> </center>  </td></tr></table> </body></html>