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

Targeting to a feature

The list of features, organized by feature clauses, appears on the left:

The class only has a few immediate features because most of its interesting features are inherited. Make sure the Editing Tool is tall enough (as on the above figure) and click the feature forth , the last one, in the Feature Tree on the left. This makes the feature the Editing Tool's current target, and scrolls the text to its declaration:

Note how both of the top target fields are now filled: the first one shows the target class, LIST , and the second one shows the target feature, forth .

Basic feature information

Now let's look at the feature views. Click the Feature Tab at the bottom of the Context Tool:

This brings up basic information on the selected feature in the Context Tool:

The bottom Context Tool shows one of the Feature views, by default Flat . The flat view of a feature, similar in concept to the flat view of a class (page 35 ), gives the full text of a feature, taking into account any inherited precondition or postcondition clauses. Here the feature as declared in the class appears in the top Editing Tool, with no precondition and an ensure then postcondition clause. But it's a redefinition of an inherited feature; the flat view in the bottom Context Tool shows the full precondition, inherited from the ancestor LINEAR , as well as the postcondition from LIST .

Flat is just one of the available Feature Views, shown by the buttons on the Feature View toolbar:

Text gives the feature text, fully clickable.

Who calls this feature?

Next to Flat is Callers . Try it now by clicking the corresponding button (the following figure and the next only show the Context Tool, where the views appear):

This view shows all the places in the system that call the routine, or one of its redefinitions. Such information can be invaluable for debugging in particular. The successive paragraphs correspond to the various versions of forth in class LIST , its ancestors and its descendants. Reading from the top we see that:

The version from LIST is called in LIST itself by the function is_equal .

The version from LIST's descendant ARRAYED_CIRCULAR is not called directly in this system, although it could be called through dynamic binding (on an entity declared of type LIST but dynamically attached to an instance of ARRAYED_CIRCULAR ).

About 60% down, forth from ARRAYED_LIST , a version in another descendant of LIST , is called by two routines of ARRAYED_CIRCULAR , one routine of ARRAYED_LIST , and two routines of MULTI_ARRAY_LIST .

Also note, in the following entry, that after renaming forth is called back in the descendant ARRAYED_STACK .

What happens to my feature through the inheritance hierarchy?

Now click the next view button, Implementers :

This is a very useful view, showing all the ancestors and descendants of LIST that provide a separate version of forth , including the original introduction of this feature in LINEAR and subsequent redeclarations (redefinitions or effectings). The mention (version from) signals the version applicable to the current class, here LIST .

Since all class and feature names on these views are hyperlinks, you can display any of the listed versions in a new Development Window by control-right-clicking it (we will see shortly how to display it in the same tool). Control-right-click on the feature name forth on the line that reads MULTI_ARRAY_LIST forth (line 4). This brings up a tool targeted to the routine forth from MULTI_ARRAY_LIST , so that you can see the implementation of the routine in that class:

You can get rid of this new Development Window (just close it, but don't exit EiffelStudio!) and come back to the original Development Window, where we still have two unexplored views, Ancestor versions and Descendant versions . Click the first of these to obtain the ancestor versions of forth from LIST :

The format is self-explanatory: for each ancestor of LIST that has a version of LIST 's forth feature, it indicates the name of that feature -- which could be something else than forth as a result of renaming, although here this happens only in descendants, not ancestors -- and the version of the feature applicable to the given class.

The list is labeled History branch #1 because in the case of feature merging (combining several features inherited from different parents, in conformance with the rules of the language) there could be more than one history branch.

The next button, Descendant versions , similarly tells you all that happens to a feature in the descendants of the current class.

Who has the same name?

The last button, Homonyms , displays all the features of the system which, related or not to the current feature by redeclaration, have the same name. You can then explore any such feature to see if the relationship is more than casual.

In any system or library that takes advantage of inheritance and its associated mechanisms -- renaming, redefinition, effecting, undefinition, multiple and repeated inheritance, polymorphism, dynamic binding -- the feature browsing facilities that we have just explored are invaluable to track what happens to features. What makes them even more precious is their connection with the rest of the browsing and documentation capabilities, especially the pick-and-drop which we will now study.