Into Eiffel by Ian Joyner (1/5)

The basic construct in Eiffel is the class. In fact there is no other construct of note. So immediately we have a language which is fundamentally simpler than C/C++ and Object Pascal.

A class represents entities, the attributes of those entities and the operations that those entities can perform. This gives you a fundamental mechanism for project organisation because any application is organized into a set of interacting classes.

Classes represent real world entities in a model, but can represent more artificial artifacts that occur only in computer programs. An example of an Eiffel class is:

class CAR end

A class represents all objects of that type. For instance, in the real world we have one concept of CAR, but there are many instances of CARs. We should be careful to distinguish between a class as a conceptual design pattern of entities and objects that represent the entities themselves.

One of the greatest promises of OO is reuse; that is, you should not have to rewrite many basic concepts that frequently appear. Classes that frequently appear are organized into libraries, such as EiffelBase for many basic types such as INTEGER, REAL, STRING, etc. Many collections are also in the base library such as LISTs and ARRAYs, with many others.

Not only do you have the EiffelBase (sometimes called Kernel and ELKS) library, but many other libraries to interface to databases, CORBA, etc. Also on the Macintosh with EiffelS for CodeWarrior, you get the MacOs Toolbox Eiffel Library, Eiffel Carbon, which is a full OO interface to the MacOS. Carbon can simply be used as an Eiffel API to MacOS, but with a single call, it becomes a full event-driven application framework like MacApp and PowerPlant, making application development even simpler. You will find Carbon cleaner and easier to understand and find what you want than any framework written in C++, and it is the consistency of the Eiffel language that enables this. Carbon also follows uniform naming patterns that many other Eiffel libraries vendors have adopted. This means that the programmer has less to remember and has to consult API references less frequently.

Libraries are not defined as part of the Eiffel language—they are simply collections of related classes.

Each class has a set of features that represent the attributes and operations of a class. Operations on an object typically alter the state of the object, that is, will change the values of one or more of its attributes. In Eiffel, such operations are known as procedures. Fields in an object can be changed only by routines in the object.

Functions are computations that return an answer to a query about the state of an object, but do not change the state of an object (although this is by convention, rather than being enforced in Eiffel). Computational functions and procedures are together known as routines. Functions, however, have more in common with reading an attribute field or even constant than with procedures. When performing a query, it does not matter to the querier whether the answer is retrieved from a pre-computed field of the object or by a computation that is done at that moment. Eiffel needs no low-level call operator such as ‘()’ to invoke functions. This makes Eiffel programs very flexible because functions with no arguments can be redefined as fields or constants.

For example, the attribute speed of a CAR object could either be stored in a field or computed from other inputs or fields stored in the object. (Indeed reading a field involves a computation of retrieving the contents of that item; this computation is in fact hidden to the programmer, which leads many to think that field access and functions are different, but really field or constant access is functional access. This is called the Principle of Uniform Access and makes software very flexible.)

Attributes themselves can be fields or constants. A field sets aside space within each created object where the value is stored. A constant is compiled into the code, and does not use up space in an object.

An example of a class with features is:

class CAR feature colour: COLOUR -- a field velocity: INTEGER is -- a function do Result := speed end wheels: INTEGER is 4 -- a constant speed: INTEGER stop is -- a procedure do speed := 0 end end -- CAR

Note that the features of a class are introduced by the keyword feature. A number of other points can be seen about Eiffel style and syntax. Comments are introduced by -- (like an em–dash, —). This indicates a comment to the end of line. Grouped entities are terminated by the keyword end. Eiffel has no begin keyword since it is superfluous. (Small syntactic problems like not putting a semicolon before an else as in Pascal are avoided in Eiffel. Remember that semicolons are merely typographical for human readability in Eiffel and therefore optional. Code in in fact more readable without semicolons.) Also superfluous are semicolons, but these may optionally be placed between constructs. Eiffel has a clean and modern syntax making programs much easier to read.

The features speed and velocity can be interchanged as queries. In fact, this is an artificial example to show only the differences and similarities between functions and fields.

In Eiffel style, keywords are shown in bold and user named entities in italics. Class names are given in uppercase, which follows the mathematical typographical convention for types. Eiffel is not case sensitive, so it is up to the programmer to follow style conventions. Entity names made up of more than one word separate the constituent words with underscore ‘_’, for example SPEEDY_CAR. (As you can see, the underscore style is more consistent than the capitalization style, SpeedyCar, which does not work for upper case type names, or constant names as in C style. The underscore style is also more readable, giving a better approximation of white space in between words.)

Note also in your editor, you will not have to enter words in bold and italics—these are done by formatting software.

C and C++ programmers might be wondering how to make features public, protected and private. With Eiffel you have far more control: any set of features introduced by the feature keyword can be exported to other specific classes. Thus you have the possibility of many shades of grey between public and private. You might want a feature to be public to some specific classes, but private to others. This also covers the friend mechanism of C++ since a special implementation relationship can be specified between certain classes.

In Eiffel there are two specific classes ANY and NONE. ANY is at the top of the inheritance hierarchy and exporting to ANY is equivalent to public. ANY is automatically inherited by all classes. It is like Object in Java, and TObject in MacApp. NONE is at the bottom of the inheritance hierarchy and exporting to NONE is the equivalent of protected in C++. There is no strict equivalent of private, as Eiffel believes it is not sensible to restrict visibility in subclasses. We will not look at the specifics of export since this is covered in longer tutorials and this is meant to be a short tutorial.