featuresmatrix intro page0. Intended Use
Eiffel is an object-oriented language designed for the specification,design implementation and modification of large applications and reusablecomponents. Its range extends over most application domains including (mostprominently) business applications.
1. Basic Concepts
Eiffel is based on a pure object model. All entities in an Eiffel programare objects and all objects are instantiated from one (and only one) basegenerating class.
An Eiffel class is an implementation of an abstract data type i.e.,a class describes the operations available to the type and formal propertiesof those operations. A class describes possible run-time objects.
Eiffel is strongly typed. Every entity is declared of a particular type.
An Eiffel program is a collection of classes with one class designatedas the `root' class from which execution begins. This involves the creationof an object of the root class and subsequent creation of other objectsby that newly created object.
2. Objects
Objects in Eiffel are instances of an abstract data type. The propertiesof abstract data types are described in a class.
An abstract data type separates the implementation of a class from the`public interface'. The public interface details the ways an object canbe manipulated through operations. There may be more than one public interfacefor a particular Eiffel class. The interface depends on the type of theobject requesting a particular operation. For example, an operation `op'may be public to class `A' but not to class `B'. See also entry under 5.Encapsulation.
Objects have an immutable identity that exists for the lifetime of theobject. The identity of all objects in an Eiffel program are unique.
Objects have unique state (i.e., the data for each object is unique).Objects of the same type share the same implementation. It is also possiblefor objects to share particular state entities among all instance of theirtype.
Entities may be either references to objects (called a reference type)or may be actual objects themselves (called expanded types). See also entryunder 9.4 Containment.
2.1 Operations
Eiffel operations are based on the classical object model. Each operationhas a recipient, an operation (applicable to the recipient) and optionalarguments.
2.2 requests
2.3 messages
Not applicable.
2.4 specification of behavioral semantics
Behavioral semantics of objects can be specified in two ways: firstby the signature of the operations and secondly by assertions in the formof preconditions, postconditions and a class invariant.
The signature of an Eiffel operation specifies the name of the operation,any formal parameters (including their types) and optionally the type ofa return result.
Assertions are used to specify contracts between two objects. The objectusing an operation of another is called a client while the object providingthe operation is the supplier.
Assertions in Eiffel are boolean expressions that must evaluate to true.The expressions may refer to any operation or attribute within the classand also any actual parameters passed to the operation.
The part of the contract binding on the client is the precondition.A precondition specifies the conditions in which an operation can be called.This may be requirements for the object to be in a particular state orfor particular values of actual parameters.
The operation must abide by the postcondition. i.e.,. the postconditionis binding on the supplier. A postcondition may refer to the value of entitiesprior to the execution of the operation. This can be used to compare `old'values with new values.
The class invariant is used to specify general consistency constraintson an object.
The properties of a loop can also be specified using assertions. Loopvariants and invariants can specify that each iteration of the loop willmake some progress towards the termination condition and values that mustbe maintained during each iteration of the loop (invariant).
Finally additional arbitrary properties of objects and their operationscan be specified using assertions in the form of `check' statements. Wherebythe assertion(s) in a check statement will be evaluated when the statementis reached.
The failure of an assertion causes an exception. Exceptions may be handledin two of ways: an attempt to fix the problem, or failure. An operationmust either succeed in its execution or fail. A failure in an operationcauses an exception in the caller.
Operations may attempt to fix the problem by catching the exceptionin a `rescue' clause. The rescue clause may try to adjust the state ofthe object so that it is correct and then either retry the operation orfail.
2.5 methods
2.6 state
The state of an Eiffel object is represented by the data stored in its`attributes'. The attributes of an object may be attached to either simpleobjects, (integers, reals, etc.) or complex objects (user defined types).
The state of an object may be accessed through the names of its attributes(depending on the publicity of those attributes). The attributes may beattached or not attached to another object. If the attribute is not attached,(i.e., is not pointing to anything) it is said to be a `Void' reference.(See also entry under 9. Noteworthy Objects).
An attribute may be either a reference type, whereby it is a reference(pointer) to an object, or it may be an expanded type, whereby it is anotherobject itself.
For example, a class with the following attributes:
a: A - attribute a of type A
b: expanded B -- attribute b of type expanded B
May appear in memory as follows:
a -----> instance of A -- a reference to an object of type A
b (an instance of B) -- b an actual object of type B
The state of an attribute can also be accessed by the values of functions(as opposed to procedures) that return some value that represents partof the state.
Via a public interface of a class, attributes and functions with noarguments appear identical. The user of the class does not need to knowwhether the object returned is an actual attribute of the class or calculatedby a function of the class.
2.7 object lifetime
The lifetime of an object in Eiffel extends from creation until it becomesunreachable. i.e., an object exists when it is created and attached tosome entity; it ceases to exist when either it has lost all referencesto it (and so becomes unreachable) or it is explicitly `forgotten' (deleted).An unreachable object is automatically garbage collected.
To make a new object in Eiffel the create construct is used ("!!")whereby a new object is created and attached to an entity, such as an attribute.During creation all simple types (integers, reals, strings, charactersand references) are initialized to default values.
Removing or forgetting an object is performed by either losing all referencesto an object or by attaching the special object Void to the entity. Forexample,
a := Void
Supposing there are no other references to the object initially attachedto a, then that object has been forgotten.
An object generally exists no longer than the lifetime of the executingprogram. However, the lifetimes of objects can be extended through theuse of persistence. A number of library classes supply the necessary functionalityfor objects to become persistent and therefore exist beyond the lifetimeof the program.
2.8 behavior/state grouping
Eiffel supports the classical model of objects.
2.9 communication model
Currently not applicable, however an implementation for concurrencyin Eiffel is being developed and may be released in future versions.
2.10 events
Not applicable.
2.11 transition rules
3. Binding
Eiffel supports both late and early binding (in general this is true,however it depends on the implementation). Operations that have been redefinedthrough inheritance utilize late binding at run-time, while operationsthat have not been redefined are statically bound at compile time.
Dynamic binding occurs depending on the `dynamic' type of the receiverobject. The correct operation for that object will be selected automaticallyby the run-time system.
4. Polymorphism
Eiffel allows entities to be attached to different object types at run-time.Polymorphism in Eiffel is constrained by inheritance. Only those objectsthat `conform' to the declared type are allowed to be attached. Conformanceof an object includes its declared type and any direct or indirect descendants.
For example, given class A, and subclasses of A being B and C. An entitydeclared as:
entity: A
can be attached to objects of type A, B and C.
Static typing ensures that there will be at least one version of alloperations requested by a client.
5. Encapsulation
Features can only be invoked through the public interface of a class.A class's public interface consists of all operations and state that are`exported'. i.e., exported features are public and can be invoked by anyclass. A feature can also be exported to a select set of classes.
For example, a class may appear as follows:
class A
feature {ANY}
a: INTEGER;
b: INTEGER;
feature {A, B, C}
c: INTEGER;
d: INTEGER;
feature {NONE}
e: INTEGER;
end; -- class A
Attributes a and b are exported to ANY (the parent of all classes) andtherefore all classes that are descendants of ANY. Attributes c and d arepublic to only classes A (the class itself), B and C. While attribute eis exported to no class (NONE).
Attributes (state) can be exported in a read-only form. This is differentto Smalltalk and other similar languages that cannot make state directlyaccessible to the public.
The implementation details of all operations are hidden in the publicinterface. Only the signature, an optional header comment and the pre-and postconditions are available in the public interface. Attributes andfunctions with no arguments also appear identical.
When inheriting there is no form of encapsulation. An inheritance relationshipinherits all features unconditionally. The exports status of inheritedfeatures is also inherited. However, this export status may be changed(with no restrictions) in the descendant. See also entry under 8. Inheritanceand Delegation.
6. Identity, Equality, Copy
All Eiffel objects are given an immutable, unique identity.
Objects can be copied using the operation `copy' from class ANY. Thisform of copy copies all fields from one object onto another. Both the sourceand target objects must be non void. The copy operation can be redefinedin subclasses to conform to local behavior. There is also a `frozen' versionthat cannot be redefined called `standard_copy'.
A copy can occur in two forms: shallow or deep copy. A shallow copywill copy the objects fields including the current contents of those fields.If the content is a reference to another object, no attempt is made torecursively copy the objects attached to the reference.
A deep copy, on the other, hand will recursively copy the entire objectstructure beginning with the source object. This is performed using theoperation `deep_copy'.
Objects can also be `cloned'. i.e., A clone will return a new objectthat is field by field equivalent to another. For example, the operation:
x := clone (y)
will attach a new object to x that is a clone of y. X, in this case,does not need to be attached to an object before the clone, as in a copyoperation. There is also a deep_clone operation that will recursively clonethe entire object structure of y.
Clone is generally defined in terms of copy and so its definition isfrozen and cannot be redefined.
The field-by-field equality of two objects attached to entities x andy can be determined by the expression:
equal (x, y)
The standard version of this expression (as defined in ANY) has a numberof rules that determine the result [1]:
1. If both x and y are Void then the result is true.
If one is Void and the other is not then the result is false.
2. If both x and y are bit sequences then equality is
determined by bit-by-bit equality. Cases 3 to 6 assume x and
y are not bit sequences.
3. If y is not the same type as x or a descendant type then
the result is false. Cases 4 to 6 assume y conforms to x.
4. If y is a simple type (character, integer, boolean real,
double or pointer) then the result is true if both objects
have the same value. After possible coercion of the heavier type.
5. If x and y are special (strings or arrays) then the value
is true if the sequences of values have the same length and each
field is (recursively) identical.
6. If x and y have the same fields and each field is identical.
i.e., every corresponding reference field of x and y points to
the same object and every object field of y is recursively equal
to the corresponding field of x.
There is also a deep_equal that will recursively test the equality ofeach reference field of x and y in case 6.
7. Types and Classes
Every object is a direct instance of exactly one type. It may also beindirectly an instance of more than one type through inheritance.
An Eiffel program (text) describes possible types through their stateand operations.
Typing in Eiffel is static. i.e., every component denoting run-timevalues is typed and the type of the component is determined by its declarationin a class text.
There are three possible kinds of types: reference type, expanded typeand formal_generic_type. The first two denote possible run-time componentsthat either reference an object or are and actual object, respectively.
Formal_generic_types represent generic parameters to be provided inactual used of the class by parents or proper descendants. See also entryunder 9.5 aggregates.
Every class is a type.
8. Inheritance and Delegation
Eiffel uses a multiple inheritance model. Subclasses may inherit fromone or more superclasses. A class may also inherit from one class manytimes. This is repeated inheritance.
Inheritance in Eiffel is used both as a module extension mechanism anda type refinement mechanism.
The problems of name clashes and conflicts caused by multiple inheritancecan be alleviated using a number of `feature_adaptation' clauses. The propertiesof inherited features can be modified in the following ways:
renaming -- to remove any name clashes, and also to provide contextspecific
names to features.
exporting -- changing the export status of features. By default theexport status of
inherited features is the same as in the parent. The export status canbe
changed.
undefining -- Changing an operation with an implementation to an operation
without an implementation. From `effected' to deferred'.
redefining -- Modifying the signature and implementation of an operation.The
signature, preconditions and postconditions must conform to the original
definition.
selecting -- Removing conflicts for dynamic binding under repeated inheritance
sharing -- merging two (or more) features from a repeatedly inheritedclass into
one feature.
joining -- merging two deferred features (with compatible signatures)into one.
9. Noteworthy Objects
All classes inherit from class ANY. This class inherits in turn fromclasses: PLATFORM (which introduces platform specific features) and GENERAL(which introduces general state and operations that are applicable to allclasses, such as copy, clone and equal).
There is also a conceptual class called NONE that inherits from allclasses. This class does not have any instances and exports no state oroperations. It is used to represent a reference that does not point toan object (Void). Class GENERAL has an entity called Void of type NONEand serves as the initialization value of all references.
9.1 relationships
A relationship between two classes is established when one class declaresan attribute, parameter or local variable, of the other class's type. Thisis a `client-supplier' relationship. The client is the class using theservices of the other. The supplier class is the class that provides theservices required by the client. The client-supplier relationship is one-way,it can only be traversed from the client side.
9.2. attributes
Attributes in Eiffel can become part of the public interface if exported.They represent the state of the object in question. When exported, theyare exported in read-only form. Only the class itself can change the valuesof its attributes.
9.3 literals
Eiffel supports literals for the basic class types: INTEGER, STRING,REAL, CHARACTER and bit sequences. There is also a manifest form for ARRAY.
9.4 containment
Containment of objects can be realized by using an expanded object.An object that contains another can either have a reference to that objector hold the object itself. When an object holds another directly it iscalled an expanded type.
This can be declared in two ways. The class to be referenced may bedeclared as expanded:
expanded class A
...
or the entity (attribute) may be declared as expanded:
a: expanded A
In both of these cases the object will be contained within another.There is no need for dereferencing. See entry under 2.6 state.
9.5 aggregates
Aggregate objects are realized through generic types. A class may bedeclared with a number of formal generic parameters that specify the typeof objects that it can operate on. For example, the HASH_TABLE class inEiffel has the following class header:
class HASH_TABLE [T, U -> HASHABLE]
...
Both T and U are generic parameters. Code within the class can referto both of these parameters as types. The parameter U is restricted bythe class HASHABLE. i.e., U must conform to HASHABLE. In this class T isthe type of object that will be stored in the structure while U is thetype of the key used in the storage management.
Such generic aggregate types include linked lists, hash tables, setsand so on. However these are not defined by the language, but are suppliedas class libraries.
9.6 other
None.
10. Extensibility
Classes can be defined in terms of other classes. See also entries under8. Inheritance and Delegation and 9. Noteworthy Objects.
10.1 dynamic
Dynamic extensibility is not supported in Eiffel.
10.2 metaclasses/metaobject protocol
Not applicable.
10.3 introspection
Limited introspection is available through class operations. Class ANYintroduces a small number of operations to find the base class of an objectand other similar information.
Most vendors supply one or more library classes to provide further facilitiesfor object introspection such as finding the number and types of fieldswithin an object and also manipulating those fields.
11. Object Languages
Eiffel is the object language itself.
12. Semantics of Base Classes (+type constructors)
Not Applicable
13. Background and References
1. Meyer, Bertrand, Eiffel: The Language (Reprinted with corrections),Prentice-Hall Object-oriented Series, 1992.
2. Meyer, Bertrand, Object-oriented Software Construction, Prentice-Hall,1988.
3. Meyer, Bertrand, Reusable Software: The Base Object-Oriented ComponentLibraries, 1994, Prentice-Hall Object-Oriented Series.