Previous Table of Contents Next


9.6.13. Information Hiding and the Call Rule

The basic form of computation, it has been noted, is a call of the form target.feature (...). This is only meaningful if feature denotes a feature of the generating class of the object to which target (assumed to be non-void) is attached. The precise rule is the following:


Feature call rule:  
A call of the form target.feature (...) appearing in a class C is only valid if feature is a feature of the base class of target’s type and is available to C.

The first condition simply expresses that if target has been declared as target: A, then feature must be the name of one of the features of A. The second condition reflects Eiffel’s application of the principles of information hiding. A feature clause, introducing one or more feature declarations, may not just appear as

   feature  -- Comment identifying the feature category
       ... Feature declaration ...
       ... Feature declaration ...
       ...

but also include a list of classes in braces, feature {A, B, ...}, as illustrated for ACCOUNT:

   feature {NONE}  -- Implementation
       all_deposits: DEPOSIT_LIST
            -- List of deposits since account’s opening.

This form indicates that the features appearing in that clause are only available—in the sense of available for calls, as used in the feature call rule—to the classes listed. In the sample feature, all_deposits is only available to NONE. Because of the global inheritance structure (section 9.5.4), this means it is in fact available to no useful client at all and is equivalent in practice to feature { } with an empty class list, but the form listing NONE explicitly is more visible and hence preferred.

With this specification, a class text including the declaration acc: ACCOUNT and a call of the form

   acc.all_deposits

violates the feature call rule and is rejected by the Eiffel compiler.

Besides fully exported features (introduced by feature ... without further qualification) and fully secret ones (feature {} or feature {NONE}), it is possible to export features selectively to some specified classes, using the specification feature {A, B, ...} for arbitrary classes A, B, and so on. By enabling a group of related classes to provide each other with privileged access, this selective export mechanism is one of the techniques that avoids the heavier solution of using meta-modules above the class level (section 9.5.5).

Exporting features selectively to a set of classes A, B, and so on also makes them available to the descendants of these classes. A feature clause beginning with just feature is equivalent to one starting with feature {ANY}.

These rules enable successive feature clauses to specify exports to different clients. In addition, the recommended style, illustrated in the examples of this chapter, suggests writing separate feature clauses—regardless of their use for specifying export privileges—to group features into separate categories. Typical categories, appearing in the order given, are Initialization (for creation procedures), Access (for general queries), Status report, Status setting, Element change, and Implementation (for selectively exported or secret features).

The feature call rule is the first of the rules that make Eiffel a statically typed approach, where the applicability of operations to objects is verified at compile time rather than during execution. Static typing is one of the principal components of Eiffel’s support for reliability in software development.


Previous Table of Contents Next