Eiffel Home Page (Web) -- Getting started with Eiffel (local)

The Class Tab

The first tab we'll look at is the Class Tab. You'll find it at the bottom of the Context Tool:

This gives you access to many forms of information about the current class -- the target of the Development Window. A set of buttons at the top of the Context Tool enables you to display a number of views of the class. The currently highlighted button indicates the default view: Ancestors . You can see the others' names by moving the cursor over the various view icons, without clicking , and reading the tooltips.

The view currently displayed, Ancestors , shows the inheritance structure that leads to the current target, LIST :

This shows that LIST is an heir of CHAIN which itself, as an example of multiple inheritance, is an heir of CURSOR_STRUCTURE , INDEXABLE , and -- twice, as an example of repeated inheritance -- SEQUENCE . If, because of direct or indirect repeated inheritance, a class appears more than once, the display doesn't repeat its ancestry the second and subsequent times; the omitted repetition appears as just three dots, … , as illustrated here for the second occurrences of BAG , ACTIVE and others.

As you may have guessed, all the class names that appear on this display, by default in blue, can function as hyperlinks: you can use any one of them to retarget the Development Window to the corresponding class. This will be another major retargeting mechanism. But let's not pursue it for the moment and instead continue looking at the documentation views.

Next to Ancestors is Descendants , which will give you the descendants of a class in a similar format:

The progeny of LIST , as you can see, is just as impressive as its ancestry.

Let's now look at the other formats, starting from the left. The first button, Clickable , gives the class text. It's essentially the same information as appears in the top Editing Tool (whose pane was reduced to its bare minimum in the last few pictures, showing only the first three lines or so), but with some differences:

The top Text view is editable. In fact it's EiffelStudio's primary tool for entering software texts. The bottom Clickable view is just a view; you can't change it.

The Text view retains the formatting of the class text the way it was typed in; the Clickable view is automatically formatted -- "pretty-printed" -- according to the standard Eiffel layout rules.

The Clickable view does not include comments inside routine implementations ( do and once clauses), although it does retain features' header comments.

As part of the pretty-printing, the Clickable view uses colors and fonts to distinguish keywords, identifiers, comments and other syntactical elements. You can change the fonts and colors, like many other elements of the interface, through Tools --> Preferences . (Now's not the time.)

This view is called "clickable" because, as we'll see later, every syntactical element on it is a hyperlink, which you can use for browsing. Here is the beginning of the LIST class text in Clickable view:

After Clickable comes the Flat view button. The layout of the result is similar:

The flat form of a class is the reconstructed class text including not only what's declared in the class itself but also everything that it inherits from its ancestors, direct or indirect. This applies to the flat form's features, which include ancestor features, but also to contracts: the flat form's invariant includes all clauses from ancestors' invariants, and the preconditions are expanded to take require else and ensure then clauses into consideration. (The Eiffel Tutorial explains these notions in detail.)

As a result, the Flat view shows the class text as it might have come out had inheritance (what a horrible thought even to contemplate!) not been available to write it.

The first two features appearing in the above display, cursor and first , are indeed inherited from ancestors, rather than declared in LIST itself. Note how EiffelStudio, when producing the flat form, adds a line of the form

-- (From CLASS_OF_ORIGIN )

to the header comments of inherited routines, to document where they come from.

The flat form is an important notion of object technology, making it possible to understand a class by itself, regardless of the possibly rich inheritance structure that led to it. Looking at the Flat view of LIST , you may note how few of its properties come from the class itself; most of the interesting work has been done in ancestors, and LIST just adds a few details.

If at any time you want to search for a certain pattern in the views displayed, click the Search button at the top of the window, or type CTRL- F . A self-explanatory Search Tool will come up, with various options such as Match case and Whole word .

Next come two essential documentation views: Contract and Flat Contract . Based on Eiffel's principles of Design by Contract, they document the interface properties of a class. Unlike the previous two, they do not show actual Eiffel texts, but information useful for client classes.

Here is the beginning of the Contract view for our example class LIST :

The contract form (also known as the short form of a class) is the class text deprived of any internal detail to retain interface information only. It discards any feature that's not exported (available to all clients); for the retained features, it discards the implementation -- do or once clause -- but retains the header (feature name, arguments, results), the header comment, and the contracts (precondition, postcondition, invariant) minus any contract clause that refers to a non-exported feature and hence would be useless to clients.

As you will know, particularly if you have read the book Object-Oriented Software Construction , the contract form is the preferred way of documenting software elements, especially reusable components, as it provides clients with just the right level of abstraction: precise enough thanks to the type signature and the contracts; clear enough thanks to the header comments; and general enough since it omits implementation details that are irrelevant to client programmers (and might lead them to write client code that won't work any more if the implementation changes).

In practice you will often want to use, instead of the Contract view, the next one, Flat Contract , also known as "flat-short form" and "interface form", which applies the same rules to the flat form rather than to the original class. This means it shows information on all the features of the class, immediate (defined in the class itself) as well as inherited, whereas the short form, non-flat, only considers immediate features. The Flat Contract view provides the complete interface information for the class. Try it now on class LIST .

The next two buttons are for the Ancestors and Descendants views, which we have already seen, showing classes connected with the target through one of the two inter-class relations, inheritance. After them come Clients and Suppliers , to list the classes connected through the other relation, client. Clicking the Clients button shows the (empty) list of clients of LIST :

No class of this system directly uses LIST as client, although some use its descendant ARRAYED_LIST . Now click the next button to see the Suppliers of LIST :

The only two classes that LIST needs for its own algorithms are basic types from the Kernel Library, BOOLEAN and INTEGER . In Eiffel, as you may remember, all types are defined by classes, even those describing such elementary values as integers and booleans.

Feature information in the Class View

Let's resist the natural urge to go see now what the classes INTEGER and BOOLEAN look like, and instead continue our survey of views. The remaining views will all display information about the features of the class. The first of them, Attributes , lists the attributes. It's not very interesting for LIST , a deferred class with only one attribute -- you can check this for yourself by clicking the Attributes button -- so let's look at the next one. Click the Routines button now to display information about the routines of class LIST :

The sections of this display group routines according to the ancestors of LIST -- including LIST itself -- that first introduced them; for example (second and third sections) extendible originally comes from COLLECTION and extend from BAG . Much of the benefit of this display comes from its support for browsing: all the colored elements, representing classes and features, will be "clickable" hyperlinks.

The remaining Class View buttons all display information in the same format. Each selects a specific subset of the target class's features. The last two selected attributes and routines. You can now try any of the others by clicking the corresponding button:

Deferred features: abstract features which don't have an implementation in the current class, only in eventual descendants. Try this for LIST ; you'll see that this deferred class indeed has a number of deferred features.

Once and constants : constant attributes, "once functions" which provide shared objects (close to the "singleton" pattern), and once procedures which provide a convenient initialization mechanism. LIST hasn't any.

External features, implemented as calls to routines, macros or other elements implemented in other languages. LIST hasn't any.

Exported features: those available to all clients. LIST has quite a few.

All the views you have now learned to produce were about classes . It's also very useful to obtain information about what happens to your features throughout the classes where they appear. This will be the purpose of the Features Tab of the Context Tool. But before we look at it let's see how to do more with the Class View facilities just seen, by exporting them to the outside world: to the Web, to a text processing tool, or in fact any other tool.