Browsing Features

    Contents
  1. Targeting to a feature
  2. Basic feature information
  3. Who calls this feature?
  4. What happens to my feature through the inheritance hierarchy?
  5. Who has the same name?

Let us get back to EiffelStudio. Before studying the documentation generation we saw how to display properties of classes. It's also interesting to explore the properties of features.

There are two tools with similar sounding names that we will use to explore features:

  1. The Features tool (plural) which provides a list of the immediate features of the class on which the development window is targeted. This tool is located by default in the vertical pane on the right hand side of the development window.
  2. The Feature tool (singular) which allows you to explore the properties of some particular feature. By default, the Feature tool is available as a tab on the lower pane of the development window along with the Class tool, Outputs tool, and others.

Your Development Window should still be targeted to class LIST, from the last view, Routines, that you displayed on it. If you've lost it, just retarget a Development Window to this class.

Let's start by making the Features tool visible. To see the Features tool click on the tab labeled (note that this is the plural "Features" versus the singular "Feature").

If the tab for the Features tool is not visible, bring it back by following the menu path:View --> Tools --> Features

While we are at it, let's get make the Feature tool visible as well. Click on the tab on the lower pane that's labeled . As with the Features tool, if the Feature tab is missing, you can use the menu path to restore it.

One more thing, and we'll look at some features. If you restarted EiffelStudio since you worked through the Viewing Classes section, you may have to select Link Context Tool again from the View menu.

Targeting to a feature

The list of features, organized by feature clauses, appears in the Features tool:

The class only has a few immediate features because most of its interesting features are inherited. Make sure the Editor 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 Editor 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 views of the feature forth provided in the Feature tool.

A view of forth is already visible in the Feature tool. By default, it is the Flat view.

The flat view of a feature, similar in concept to the flat view of a class, 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 toolbar of the Feature tool.

You can mouse-over the different buttons to see the views they represent.

Just to the left of Flat, Basic Text gives the feature text, fully clickable.

Who calls this feature?

To the right of Flat is Callers. Try it now by clicking the corresponding button. You may have to scroll down some in the display to see the series of entries show in the image below;

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'll examine a few entries:

  • The version from LIST is called in LIST itself by the function is_equal.
  • The version from LIST is called in routines in two debugger classes RT_DBG_CALL_RECORD and RT_DBG_COMMON
  • The version forth from MULTI_ARRAY_LIST is a version in a descendant of LIST, and is called by three routines of MULTI_ARRAY_LIST itself: duplicate, put_right, and remove_right.
  • Although it is not shown in the figure, if you scroll around some, you will find cases in which a descendant of forth has been renamed and that renamed version is called. For example child_forth from LINKED_TREE is descendant version of forth and is called by routines in LINKED_CURSOR_TREE and LINKED_TREE.

The following five view buttons are similar except that they let you specify what kind of callers you are looking for, or what is being called by the currently selected feature. Feel free to explore these views.

What happens to my feature through the inheritance hierarchy?

After the caller/callee views, the next view button is 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). Right-click on the feature name forth on the line that reads MULTI_ARRAY_LIST forth. This brings up a context menu and chose Show --> Text. The tool is now targeted to the routine forth from MULTI_ARRAY_LIST, so that you can see the implementation of the routine in that class.

We still have two unexplored views, Ancestor versions and Descendant versions. Click the first of these to obtain the ancestor versions of forth from MULTI_ARRAY_LIST.

The format is self-explanatory: for each ancestor of MULTI_ARRAY_LIST that has a version of MULTI_ARRAY_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.

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, in this case each branch is labeled Branch #X.

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.