Eiffel (1220/eif001)

Logo for eiffel

Class-based object oriented C  

Bertrand Meyer ca. 1986. An object-oriented language.

Classes with multiple and repeated inheritance, deferred classes (like Smalltalk's abstract class), and clusters of classes. Objects can have both static and dynamic types. The dynamic type must be a descendant of the static (declared) type. Dynamic binding resolves clashes from the multiple inheritance. Flattened forms of classes, in which all of the inherited features are added at the same level. Generic classes parametrized by type. Persistent objects, garbage collection, exception handling, interface to routines written in other languages. Implemented as a C preprocessor.

a sophisticated language striving for OO purity.  It is an advanced OOL that emphasizes the design and construction of high-quality and reusable software. Classes with multiple and repeated inheritance, deferred classes, and clusters of classes. Objects can have both static and dynamic types. The dynamic type must be a descendant of the static (declared) type. Dynamic binding resolves clashes from the multiple inheritance. Best for assertions. Has built in support for Design by Contract

Related languages
C => Eiffel   Compiled to
Smalltalk => Eiffel   Influence
Eiffel => AGLOO   Extension of
Eiffel => Eiffel 3   Evolution of
Eiffel => Eiffel**   Extension of
Eiffel => Green   Incorporated some features of
Eiffel => LACE   Subsystem
Eiffel => Ruby   Influence
Eiffel => Sather 0   Influence
Eiffel => SDL   Subsystem
Eiffel => SmallEiffel   Implementation
Eiffel => Visual Eiffel   Extension of

  • Meyer, Bertrand "Eiffel: The Language", P-H 1992. Interactive Software Eng, Goleta CA, (805) 685-1006. Version 2.3.4. view details
  • Switzer, R. (1993). Eiffel : an introduction. New York, Prentice Hall. view details
  • Abadi, Martin and Cardelli, Luca "A Theory of Objects" Springer Monographs in Computer Science, 1996 view details
  • Bertrand Meyer "Object-Oriented Software Construction" 2nd ed ISE Inc view details Extract: Introduction

    Born in a log cabinet, C quickly rose to prominence. Although most people interested in both C and object technology have focused on the O-O extensions of C discussed in the next chapter (C++, Objective-C, Java), it remains interesting to see how C itself can be made to emulate O-O concepts, if only to understand the techniques that have made C so useful as a stepping stone towards the implementation of more advanced languages.

    Some context C was designed at AT&T’s Bell Laboratories as a portable language for writing operating systems. The first version of Unix had used assembly language, but a portable version soon appeared necessary, and C was designed around 1970 to make it possible. It was derived from ideas found in BCPL, a language of the sixties which, like C, can be mentioned in the same breath as “high-level”, “machine-oriented” and “portable”: highlevel thanks to control structures comparable to those of Algol or Pascal; machineoriented because you can manipulate data at the most elementary level, through addresses, pointers and bytes; portable because the machine-oriented concepts are so defined as to cover a wide variety of computer types.

    C’s timing could not have been better. In the late seventies Unix became the operating system of choice for many universities, and C spread with it. Then in the eighties the microcomputer revolution burst out, and C was ready to serve as its lingua franca — more scalable than Basic, more flexible than Pascal. At the same time Unix also enjoyed some commercial success, and along with Unix still came C. In a few years, a boutique product became the dominant language in large segments of the computing industry, including much of where the action really was.

    Anyone interested in the progress of programming languages — even people who do not care too much for the language itself — has a political debt to C, and sometimes a technical one as well:

    • Politically, C ended the fossilized situation that prevailed in the programming language world until around 1980. No one in industry wanted to hear (particularly after the commercial failure of Algol) about anything else than the sacred troika, Fortran for science, Cobol for business and PL/I for true blue shops. Outside of academic circles and a few R&D departments, any attempt at suggesting other solutions was met with as much enthusiasm as if it were a proposal to introduce a third brand of Cola drink. C broke that mindset, making it acceptable to think of the programming language as something you choose from a reasonably broad and evolving catalog. (A few years later, C itself became so entrenched that in some circles the choices seemed to have gone from three to one, but it is the fate of successful subversives that they become the new Establishment.)

    • Technically, the portability and machine-closeness of C have made it an attractive solution as a target language of compilers for higher-level languages. The first C++ and Objective-C implementations used this approach, and compilers for many other languages, often having no visible connection to C, have followed their example.

    The advantages for the compiler writers and their users are: portability, since you can have a single C-generating compiler for your language and use C compilers (available nowadays for almost any computer architecture) to take care of platform dependencies; efficiency, since you can rely on the extensive optimization techniques that have been implemented in good C compilers; and ease of integration with ubiquitous C-based tools and components.

    With time, the contradiction between the two views of C — high-level programming language, and portable assembly language — has become more acute. Recent evolution of the ANSI standard for C (first published in 1990, following the earlier version known as K&R from the authors of the first C book, Kernighan and Ritchie) have made the language more typed — and hence less convenient for its use as a compiler’s target code. It has even been announced that forthcoming versions will have a notion of class, obscuring the separation from C++ and Java.

    Although an O-O extension of C simpler than C++ and Java may be desirable, one can wonder whether this evolution is the right one for C; a hybrid C-based O-O language will always remain a strange contraption, whereas the idea of a simple, portable, universally available, efficiently compilable machine-oriented language, serving both as a target language for high-level compilers and as a low-level tool for writing very short routines to access operating system and machine-dependent facilities (that is to say, for doing the same thing that assembly language used to do for C, only at the next level) remains as useful as it ever was.
    External link: online copy
  • Naftaly Minsky and Partha Pal "Law-Governed Regularities in Object Systems; Part 2: the Eiffel Case" In Theory and Practice of Object Systems (TOPAS) (John Wiley) 1997; view details
  • Snyder, Alan A. and Brian N. Vetter Eiffel: An Advanced Introduction 1997 view details External link: online Extract: About Eiffel
    Eiffel is a pure object-oriented programming language designed with the explicit intent to produce high quality, reliable software. It is pure in its nature in that every entity is an object declared of an explicitly stated class type. It adheres to some of the long proven and time tested programming practices that have made languages like Modula-2 a successful engineering advancement.
    Eiffel promises to be the next step toward a better understanding and more importantly, efficient use of the object-oriented practices that have evolved thus far. This paper intends to familiarize the reader with Eiffel's concepts and its sometimes unique approach to constructs. This is not intended to be an introduction to the object-oriented programming paradigm in general. Familiarity with programming (procedural, hybrid object-oriented/procedural, or pure object-oriented) is very helpful, as the material presented is in such a form that certain concepts must bee understood on the reader's part prior to reading this.
  • Library of Congress Subject Headings E36 view details