1Introduction

1Introduction

Eiffel is an object-oriented programming language developed by Bertrand Meyer in 1985 at Interactive Software Engineering (ISE). Named after Gustave Eiffel, the engineer who designed the famous French tower of the same name, Eiffel emphasizes the design and construction of high quality, reusable software including a language, a methodology, libraries, and development environments. The language is neither a superset nor an extension of any existing language. Eiffel strongly encourages object-oriented programming and disallows dangerous practices of previous generation languages. Eiffel supports the concept of "Design by Contract" to improve software correctness.

Eiffel is a small language, not much bigger (by such a measure as the number of keywords) than Pascal. It was meant to be a member of the class of languages which programmers can master entirely, as opposed to languages of which most programmers know only a subset. Yet it is appropriate for the development of industrial software systems, as has shown by many full-scale projects, some in the thousands of classes and hundreds of thousands of lines, in companies around the world.

2. Design Principles and Goals

The fundamental aim of Eiffel is quality software. Eiffel was designed to help specify, design, implement and modify quality software. This goal of quality in software is a combination of many factors; the language design concentrated on the three factors: reusability, extendibility, and reliability. Also considered important were other factors such as efficiency, openness, and portability [1].

Reusability is the ability to produce components that may be used in many different applications. Central to the Eiffel approach is the language's support for the production of new libraries and the presence of predefined libraries such as EiffelBase. Extendibility is the ability to produce easily modifiable software. It is historically difficult to modify software systems, especially large ones. Reusability and extendibility play important roles among quality factors: satisfying them means having less software to write, and hence more time to devote to other important goals such as efficiency, ease of use, or integrity. The third fundamental factor is reliability. Reliability is defined as the ability to produce software that is correct and robust. Eiffel techniques such as static typing, assertions, disciplined exception handling, and automatic garbage collection are essential here. To achieve reusability, extendibility and reliability, the principles of Eiffel’s object-oriented design provide the best known technical answer.

Three other factors are also part of Eiffel's principal goals. The language enables implementers to produce high efficiency compilers, so that systems developed with ISE Eiffel may run under speed and space conditions similar to those of programs written in lower-level languages. The goal of ensuring openness is desired so that Eiffel software may cooperate with programs written in other languages. Also, guaranteeing portability by a platform-independent language definition is a desired goal so that the same semantics may be supported on many different platforms [1].

3. Language Features

Eiffel is described as a “pure” object-oriented language in the sense that it was designed specifically to support object-oriented programming only and it is not based on any existing language. As a language, it is arguably the most systematic application of object-oriented principles in existence based on a small number of powerful concepts. Its modularity is based on classes; subprograms can only be enacted through objects of a class. It stresses reliability, and facilitates design by contract. It brings design and programming closer together. It encourages the reuse of software components. Eiffel offers classes, multiple inheritance, polymorphism, static typing and dynamic binding, constrained and unconstrained genericity, a disciplined exception mechanism, systematic use of assertions to promote programming by contract, and deferred classes for high-level design and analysis.

1. 
   Classes
   

Classes in Eiffel are similar to those of other object-oriented languages like C++ and Java. However, Eiffel does introduce some new terminology and keywords. A class can be defined as an implementation of an abstract data type. This means that it describes a set of run-time objects, characterized by the operations applicable to them, and by the formal properties of these operations. These operations can either be methods called routines or instance variables called attributes. The routines and attributes of a class together are called its features. The run-time objects are called the direct instances of the class.

To see what an Eiffel class looks like, let’s look at a simple example provided in Eiffel: The Language. The class ACCOUNT describes bank accounts. This class may be used by other classes, called its clients, which provide useful insight when explored. A class X may become a client of ACCOUNT by declaring one or more instances or “entities” of type ACCOUNT. Such a declaration is of the form:
acc: ACCOUNT
The term "entity" generalizes the more common notion of "variable". An entity declared of a reference type, such as acc, may at any time during execution be binded to an object; the type rules imply that this object must be a direct instance of ACCOUNT or of a subclass of ACCOUNT. An entity is said to be void if it is not binded to any object. By default, entities are void at initialization. To obtain objects at run-time, a routine r appearing in the client class X may use a creation instruction of the form
!! acc
which creates a new direct instance of ACCOUNT, binds acc to that instance, and initializes all its fields to default values. Below is a first sketch of how class ACCOUNT itself might look. Line beginning with -- are comments. The class includes two feature clauses, introducing its features. The first begins with just the keyword feature, without further qualification; this means that the features declared in this clause are available to all clients of the class. The second clause is introduced by feature {NONE} to indicate that the feature that follows, called add, isn’t available to any clients. What appears between the braces is a list of client classes to which the corresponding features are available; NONE is a special class of the Kernel Library, which has no instances. So that add is in effect a private or secret feature, available only locally to the other routines of class ACCOUNT. So in a client class such as X, the call acc.add (-3000) would be invalid.

class ACCOUNT feature

balance: INTEGER

owner: PERSON

minimum_balance: INTEGER is 1000
open (who: PERSON) is -- Assign the account to owner who.

do

end
deposit (sum: INTEGER) is -- Deposit sum into the account.

do

add (sum)

do

end
may_withdraw (sum: INTEGER): BOOLEAN is -- Is there enough

-- money to withdraw sum?

do

end
feature {NONE}

do

end
end -- class ACCOUNT

The language definition guarantees automatic initialization after a creation instruction. Each type has a default initial value, used for initialization: zero for INTEGER and REAL, false for BOOLEAN, null character for CHARACTER, and a void reference for reference types. The class designer may also provide clients with different initialization options. The other public features, open, deposit, withdraw and may_withdraw are straightforward routines. The special entity Result, used in may_withdraw, denotes the function result; it is initialized on function entry to the default value of the function's result type. The private procedure add serves solely for the implementation of the public procedures deposit and withdraw. The clause is 1000 introduces minimum_balance as a constant attribute, which will not occupy any space in instances of the class; in contrast, every instance has a field for every non-constant attribute such as balance.

In Eiffel's object-oriented programming style any operation is relative to a certain object. Within the class, however, the current instance to which operations apply usually remains implicit. If a programmer needs to denote the current object explicitly, he may use the special entity Current. For example the unqualified occurrences of add appearing in the above class are equivalent to Current.add. Eiffel also supports infix and prefix notation for routines, which will sometimes be more convenient than dot notation. To implement an addition routine, it suffices to give the routine a name of the form infix "+" rather than plus; internally, however, the operation is still a normal routine call. Prefix operators are similarly available.

2. 
   Type System
   

Classes serve as the sole basis for both the module structure and the type system. Eiffel was designed to be a strongly typed language for the purposes of readability and reliability. Every entity is declared to be one of two types. It may be either a reference type or an expanded type. Any type T is based on a class, which defines the operations that will be applicable to instances of T. The difference between the two categories of type affects the semantics of an entity x declared of type T: for a reference type, the most common case, possible values for x are references to objects; for an expanded type, the values are objects. In both cases, the type rules guarantee that the objects will be instances of T.

A non-expanded class such as ACCOUNT yields a reference type. As a result, an entity of type ACCOUNT, such as acc denotes possible run-time references to objects of type ACCOUNT. In contrast, the value of an entity acc declared of type expanded ACCOUNT is an object with no reference. The only difference is that the value of acc is now an ACCOUNT object, not a reference to such an object. No creation instruction is needed in this case. An important group of expanded types, based on library classes, includes the basic types INTEGER, REAL, DOUBLE, CHARACTER and BOOLEAN. Clearly, the value of an entity declared of type INTEGER should be an integer, not a reference to an object containing an integer value. Operations on these types are defined by prefix and infix operators such as "+" and "<".

As a result of these conventions, the type system is uniform and consistent: all types, including the basic types, are defined from classes, either as reference types or as expanded types. In the case of basic types, for obvious reasons of efficiency, the ISE Eiffel compilation mechanism implements the standard arithmetic and boolean operations directly through the corresponding machine operations, not through routine calls. But this is only a compiler optimization, which does not hamper the conceptual homogeneity of the type edifice.

Eiffel is said to be a strongly typed language because its type system cannot be violated. There are no holes in the Eiffel type system. The design of Eiffel makes it possible to catch all type errors at compile time, so that an Eiffel program cannot abort with a run time type error. However, to detect a set of certain more obscure type errors at compile time, the compiler must analyze the way that classes interact within the entire system rather than just looking at each class individually. The main types of errors that cannot be checked easily are [2]:
i. restriction of exports in a descendant class.

ii. covariant redefinition of routines parameters as in question LDBC.

iii. covariant signatures in conforming types of a generic class (like 'put' in LIST[ANY] and LIST[STRING])
There is a proposal underway that, if accepted, will allow compilers to incrementally check these types of errors by looking at classes and not at the whole system every time. Because system-wide compile-time validity checking can be complex, no compiler available today implements full static type checking. Some insert run-time checks. On the other hand, the cases where system level validity problems can occur are infrequent so in practice, it is not seen as a major problem [2].

3. 
   Assertions
   

Eiffel encourages software developers to express formal properties of classes by writing assertions, which may in particular appear in the following roles [1]:

i. Routine preconditions express the requirements that clients must satisfy whenever they call a routine. For example the designer of ACCOUNT may wish to permit a withdrawal operation only if it keeps the account's balance at or above the minimum. Preconditions are introduced by the keyword require.
ii. Routine postconditions, introduced by the keyword ensure, express conditions that the routine guarantees on return, if the precondition was satisfied on entry.
iii. A class invariant must be satisfied by every instance of the class whenever the instance is externally accessible: after creation, and after any call to an exported routine of the class. The invariant appears in a clause introduced by the keyword invariant, and represents a general consistency constraint imposed on all routines of the class.
The following code taken from Eiffel: The Language has been modified to include appropriate assertions. The ACCOUNT class becomes:
class ACCOUNT creation

make

require

do

ensure

end;
withdraw (sum: INTEGER) is -- Withdraw sum from the account.

require

sum >= 0

sum <= balance - minimum_balance

do

ensure

end;
may_withdraw -- As before

require -- balance initial.

initial >= minimum_balance

do

end
invariant

end -- class ACCOUNT

1. 
   Creation procedures
   

The class now includes a creation procedure, make. With the first version of ACCOUNT, clients used a creation instruction such as !! acc to create an account. However, in this case the default initialization violates the invariant by setting balance to zero. By having creation procedures, listed in the creation clause at the beginning of the class, a class offers a way to override the default initializations. The effect of

2. 
   Design by Contract
   

Syntactically, assertions are boolean expressions, with a few extensions such as the old notation. The semicolon is equivalent to an “and,” but permits individual identification of the components.

Assertions play a central part in the Eiffel method for building reliable object-oriented software. They serve to make explicit the assumptions on which programmers rely when they write software elements that they believe are correct. Writing assertions, in particular preconditions and postconditions, amounts to spelling out the terms of the contract, which governs the relationship between a routine and its callers. The precondition binds the callers; the postcondition binds the routine. For example, preconditions (require clauses) are simple boolean statements that are used to check that the input arguments are valid and that the object is in a reasonable state to do the requested operation. If not, an exception is generated. Similarly, postconditions (ensure clauses) make sure that a method has successfully performed its duties, thus “fulfilling its contract” with the caller. Invariants are boolean expressions that are checked every time an object method returns back to a separate object.

A developer can use these ideas in any object-oriented programming language, but he usually must supply his own assertion mechanisms or rely on programmer discipline. In Eiffel, the ideas are integrated into the whole fabric of the environment. The are found to be used by [2]:

Tracebacks almost always identify the correct culprit code since preconditions almost always denote an error in the calling method, while postconditions denote an error in the called method.

Assertions can be disabled entirely or selectively by type on a per class basis.

Invariants, preconditions and postconditions are all inherited in a manner that makes logical sense. Assertion expressions are not allowed to produce side effects so they can be omitted without effect.

Preconditions and postconditions are important statements about what a method does, often effectively describing the “contract” between the caller and callee. Invariants can yield information about legal states that an object can have.

The underlying theory of Design by Contract, the centerpiece of the Eiffel method, views software construction as based on contracts between clients (callers) and suppliers (routines), relying on mutual

obligations and benefits made explicit by the assertions.

4. 
   Exception Handling
   

Whenever there is a contract, the risk exists that someone will break it. This is where exceptions come in.

Exceptions may arise from several causes. One is assertion violations, if assertions are monitored. Another is the occurrence of a signal triggered by the hardware or operating system to indicate an abnormal condition such as a divide by zero. Unless a routine has made specific provision to handle exceptions, it will fail if an exception arises during its execution. Failure of a routine is a third cause of exception: a routine that fails triggers an exception in its caller.

Eiffel’s exception handling mechanism employs the resumption model. A routine may handle an exception through a rescue clause. This optional clause attempts to recover by bringing the current object to a stable state (one satisfying the class invariant). Then it can terminate in either of two ways:

An example, from Eiffel: The Language, using the exception mechanism is a routine attempt_transmission, which tries to transmit a message over a phone line. The actual transmission is performed by an external, low-level routine transmit. Once started, however, transmit may abruptly fail, triggering an exception, if the line is disconnected. Routine attempt_transmission tries the transmission at most 50 times; before returning to its caller, it sets a boolean attribute successful to true or false depending on the outcome. The text of the routine is as follows:

-- Try to transmit message, at most 50 times.

-- Set successful accordingly.

local

do

transmit (message); successful := true

else

successful := false

rescue

end
Initialization rules ensure that failures, a local entity, is set to zero on entry. This example illustrates the simplicity of the mechanism. The rescue clause never attempts to achieve the routine's original intent. This is the sole responsibility of the body (the do clause). The only role of the rescue clause is to clean up the objects involved, and then either to fail or to retry.

This disciplined exception mechanism is essential for software developers, who need protection against unexpected events, but cannot be expected to sacrifice safety and simplicity to pay for this protection.

5. 
   Genericity and Inheritance
   

Eiffel’s modularity based on classes does not in itself ensure reusability and extendibility. Building classes as implementations of abstract data types yields systems with a solid architecture but that is not enough. Two key techniques address the problem: genericity (unconstrained or constrained) and inheritance.

1. 
   Genericity
   

To make a class generic is to give it formal generic parameters representing arbitrary types, as in these examples from the Kernel and Data Structure Libraries of EiffelBase:

LIST [G]

LINKED_LIST [G]
These classes describe data structures containing objects of a certain type such as arrays, lists without commitment to a specific representation, and lists in linked representation. The formal generic parameter G represents this type. Each of these classes describes a type template. To derive a directly usable type, you must provide a type corresponding to G, called an actual generic parameter; this may be either a basic expanded type (such as INTEGER) or a reference type. Here are some possible generic derivations:
il: LIST [INTEGER]

aa: ARRAY [ACCOUNT]

aal: LIST [ARRAY [[G]]
As the last example indicates, an actual generic parameter may itself be generically derived. Without genericity, it would be impossible to obtain static type checking in a realistic object-oriented language. This is a description of the unconstrained form of genericity.

A variant of this mechanism, constrained genericity, will enable a class to place specific requirements on possible actual generic parameters.

2. 
   Inheritance
   

Inheritance, the other fundamental generalization mechanism, makes it possible to define a new class by the specialization of an existing class or in the case of multiple inheritance, by the combination of multiple existing classes rather than from scratch.

The parent of a class is specified with the inherit clause, as in:

class square

inherit rectangle

...

parent
feature

-- features defined here are visible to clients and

-- subclasses

-- features defined here are hidden from clients but

-- visible to subclasses
feature {none}

-- features defined here are hidden from both clients and

-- subclasses

...

3. 
   Deferred Classes
   

Deferred routines and classes are other major components of Eiffel’s inheritance mechanism. Abstract classes are defined by adding the deferred reserved word at the beginning of the class definition, as in:

deferred class C
Declaring a routine r as deferred in a class C expresses that there is no default implementation of r in C;

such implementations will appear in eventual descendants of C. A class which has one or more deferred

routines is itself said to be deferred. A non-deferred routine or class is said to be effective. Any subclass of a deferred class that is not itself deferred must of course include definitions of the deferred features of the parent.

For example, a system used by a Department of Motor Vehicles to register vehicles could include a class of the form [1]:

do... end

do... end

-- Register vehicle for year.

require

dues_paid (year)

deferred

ensure

end
... Other features, deferred or effective...

Deferred classes describe a group of implementations of an abstract data type rather than just a single implementation. A deferred class may not be instantiated: !! v is invalid if v is an entity declared of type VEHICLE. However, such an entity may be assigned a reference to an instance of a non-deferred descendant of VEHICLE.

For example, assuming CAR and TRUCK provide effective definitions for all deferred routines of VEHICLE, the following will be valid [1]:

...

Deferred classes are particularly useful at the design stage. The first version of a module may be a deferred class, which will later be refined into one or more effective classes. Particularly important for this application is the possibility of associating a precondition and a postcondition with a routine even though it is a deferred routine, and an invariant with a class even though it is a deferred class. This enables the designer to attach precise semantics to a module at the design stage, long before making any implementation choices.

These possibilities make Eiffel an attractive alternative to Program Design Languages. The combination of deferred classes to capture partially understood concepts, assertions to express what is known about their semantics, and the language's other structuring facilities (information hiding, inheritance, genericity) to obtain clear, convincing architectures, yields a higher-level design method. A further benefit, of course, is that the notation is also a programming language, making the development cycle smoother by reducing the gap between design and implementation. The role of Eiffel in this cycle is not limited to design and implementation but extends to the earliest stage of development, analysis. Deferred classes written at that stage describe not software objects, but objects from the external reality's model (documents, airplanes, investments). The presence of assertions to express constraints, and the language's other structuring facilities, provide an attractive alternative to older methods and notations [1].

4. 
   Multiple Inheritance
   

Eiffel supports multiple inheritance, which is specified by simply having more than one inherit clause. It is a careful and effective approach to multiple inheritance, which involves renaming, selection, redefinition, undefinition, and repeated inheritance. The following simple example, from the Data Structure Library in EiffelBase, is typical. LIST, as indicated, describes lists in any meaningful representation. One such representation if the lists have a fixed number of elements uses an array. We may define the corresponding class by combination of LIST and ARRAY, as follows [1]:

LIST [G];

export ... See below ... end

feature

-- Specific features of fixed-size lists ...

An heir class such as ARRAYED_LIST needs the ability to define its own export policy. By default, inherited features keep their export status (publicly available, secret, available to selected classes only); but this may be changed in the heir. Here, for example, ARRAYED_LIST will export only the exported features of LIST, making those of ARRAY unavailable directly to ARRAYED_LIST's clients. The syntax to achieve this is straightforward:

LIST [G];

export {NONE} all end

...
Another example of multiple inheritance comes from a windowing system based on a class WINDOW, close to actual classes in EiffelVision. Windows have graphical features: a height, a width, a position, routines to scale windows, move them, and other graphical operations. The system permits windows to be nested, so that a window also has hierarchical features: access to subwindows and the parent window, adding a subwindow, deleting a subwindow, attaching to another parent and so on. Rather than writing a complex class that would contain specific implementations for all of these features, it is preferable to inherit all hierarchical features from TREE (a class in EiffelBase describing trees), and all graphical features from a class RECTANGLE.

The primary argument in favor of multiple inheritance is that it yields remarkable economies of effort (whether for analysis, design, implementation or evolution) and has a profound effect on the entire software development process. However, there are problems that arise when dealing with inheritance. The very power of inheritance demands adequate means to keep it under control. Multiple inheritance, in particular, raises the question of name conflicts between features inherited from different parents; this case will inevitably arise in practice, especially for classes contributed by independent developers. In Eiffel, such name conflicts are handled through renaming, as in

As a further facility to protect against misusing the multiple inheritance mechanism, the invariants of all parent classes automatically apply to a newly defined class. So classes may not be combined if their invariants are incompatible.

5. 
   Combining Genericity and Inheritance
   

Genericity and inheritance, the two fundamental mechanisms for generalizing classes, may be combined in one of two advantageous ways. The first technique yields polymorphic data structures [1]. Assume that in the generic class LIST [G], the insertion procedure put has a formal argument of type G, representing the element to be inserted. Then with a declaration such as

Structures such as pl may contain objects of different types, hence the name “polymorphic data structure”. Such polymorphism is, again, made safe by the type rules: by choosing an actual generic parameter (POLYGON in the example) based higher or lower in the inheritance graph, you extend or restrict the permissible types of objects in pl. A fully general list would be declared as

The other mechanism for combining genericity and inheritance is constrained genericity [1]. By indicating a class name after a formal generic parameter, as in

Unconstrained genericity, as in LIST [G], may be viewed as an abbreviation for genericity constrained by ANY, as in

6. 
   Polymorphism and Dynamic Binding
   

Inheritance isn’t just a module combination and enrichment mechanism. Inheritance also allows for ad hoc polymorphism. Eiffel does not allow for function overloading or “multiple polymorphism” as it is sometimes called. In Eiffel, no two features of a class may have the same identifier, regardless of their respective signatures. This prevents the use of function overloading, which is a common programming technique in languages like C++.

Eiffel is designed to be minimal: it includes exactly the features that its designer considered necessary, and nothing else. Because Eiffel already supports (single) polymorphism through its inheritance system, the only benefit of function overloading is a reduction in the number of feature names that have to be learned. This is at the expense of reducing the ability of the compiler to trap mistakes (often type errors).

Readability is also enhanced when overloading is not possible. With overloading, the type of the arguments would need to be considered as well as the type of the target before the correct feature call can be determined. With multiple inheritance and dynamic binding this is awkward for a compiler and error-prone for a human. There is no intuitive rule which could be used to disambiguate routine calls where

there is no “nearest” routine. However, in Eiffel it's easy to write one routine with arguments of the most general applicable type, then use the assignment attempt operator to carry out the appropriate operation according to the run-time type of the arguments (thereby explicitly programming the disambiguation “rules”).

The lack of multiple polymorphism may force programmers to write some common operations in an awkward way, and may force arithmetic expressions to be treated specially. But no one has come up with a solution that is so simple, elegant, and useful that it improves the quality of Eiffel as a whole.

In Eiffel, the type of polymorphism that is allowed must be reconciled with static typing. The language convention is simple: an assignment of the form a := b is permitted not only if a and b are of the same type, but more generally if a and b are of reference types A and B, based on classes A and B such that B is a descendant of A. This corresponds directly to the substitutability principle. What makes this possibility particularly powerful is the complementary facility: feature redefinition. A class may redefine some or all of the features that it inherits from its parents. For an attribute or function, the redefinition may affect the type, replacing the original by a descendant; for a routine it may also affect the implementation, replacing the original's routine body by a new one.

Assume for example a class POLYGON, describing polygons, whose features include an array of points representing the vertices and a function perimeter that computes a polygon's perimeter by summing the successive distances between adjacent vertices. An heir of POLYGON may begin as:

redefine perimeter end

-- Rectangle-specific version

do

Result := 2 * (side1 + side2)

... Other RECTANGLE features ...

!! p; !! r;

...

if c then

end
print (p.perimeter)

All bindings of messages to methods in Eiffel are dynamic. Routines in subclasses can override inherited routines. To be an overriding routine, the types of the formal parameters must be assignment compatible with those of the overridden routine. Furthermore, the return type of the overriding routine must be assignment compatible with that of the overridden routine. All overriding features must be defined in a redefine clause. Access to overridden features can be maintained by putting their names in a rename clause.

Dynamic binding provides a high degree of flexibility. The advantage for clients is the ability to request an operation (such as perimeter computation) without explicitly selecting one of its variants; the choice only occurs at run-time. This is essential in large systems, where many variants may be available; each component must be protected against changes in other components. This technique is particularly attractive when compared to its closest equivalent in traditional approaches. In Pascal or Ada, you would need records with variant components, and case instructions to discriminate between variants. This means that every client must know about every possible case, and that any extension may invalidate a large body of existing software. These techniques support a development mode in which every module is open and incremental. When you want to reuse an existing class but need to adapt it to a new context, you can always define a new descendant of that class (with new features, redefined ones, or both) without any change to the original. This facility is of great importance in software development, an activity which -- whether by design or by circumstance -- is invariably incremental.

The power of polymorphism and dynamic binding demands adequate controls. First, feature redefinition is explicit. Second, because the language is typed, a compiler can check statically whether a feature application a.f is correct. In contrast, dynamically typed object-oriented languages defer checks until run-time and hope for the best. If an object “sends a message” to another one just expects that the corresponding class, or one of its ancestors, will happen to include an appropriate routine; if not, a run-time error will occur. Such errors will not happen during the execution of a type-checked Eiffel system. The language reconciles dynamic binding with static typing. Dynamic binding guarantees that whenever more than one version of a routine is applicable the right version, the one most directly adapted to the target object, will be selected. Static typing means that the compiler makes sure there is at least one such version.

Assertions provide a further mechanism for controlling the power of redefinition. In the absence of specific precautions, redefinition may be dangerous. How can a client be sure that evaluation of p.perimeter will not in some cases return the area? Preconditions and postconditions provide the answer by limiting the amount of freedom granted to eventual re-definers. The rule is that any redefined version must satisfy a weaker or equal precondition and ensure a stronger or equal postcondition than in the original. It must stay within the semantic boundaries set by the original assertions.

1. Conclusion

Eiffel is a pure object-oriented language. Its support for that this programming paradigm is similar to that of Java. In neither case is procedural programming supported, and in both cases nearly all bindings of messages to methods are dynamic. Eiffel’s modularity is based on classes. It stresses reliability, and facilitates design by contract. It brings design and programming closer together. It encourages the

re-use of software components.

Eiffel features seamless development. It is applicable to the entire lifecycle, from analysis and high-level design to implementation and maintenance, providing a single conceptual framework throughout the software process. Eiffel classes serve as the sole basis for both the module structure and the type system. Inheritance in the language is useful for classification, subtyping and reuse. Eiffel also features a careful and effective approach to multiple inheritance. Assertions for writing correct and robust software, debugging it, and documenting it automatically are included in the language. Disciplined exception handling to recover gracefully from abnormal cases is an Eiffel feature. Eiffel is also Statically typed and safe with no loopholes in the type system. Dynamic binding is included for flexibility and safety. Genericity, constrained and unconstrained, for describing flexible container structures is a feature of the language. And, Eiffel has an open architecture providing easy access to software written in other languages such as C, C++ and others.

Eiffel has an elegant design and programming style and is one of the easier languages to learn.

2. References

[1] Meyer, Bertrand. Eiffel: The Language. Prentice Hall. 1999

[2] Arnaud, Franck. “Eiffel: Frequently Asked Questions.” comp.lang.eiffel

archive name: eiffel-faq. 1998.

[3] Sebesta, Robert. Concepts of Programming Languages.

Addison Wesley. 4^th edition. 1998.