Introduction to Eiffel
Multiple inheritance is a big win under Eiffel. If you have dealt with this in other languages you may be surprised. Multiple inheritance entails many sticky problems, including name collisions and complications of repeat inheritance, and in most other languages is best avoided whenever possible.
When two classes inherited by common descendent have different features of the same name, a name collision obtains.
When a feature is inherited more than once from a common ancestor along two or more inheritance paths, you have repeat inheritance. This may cause a name collision and also raises practical problems, such as which repeated feature to use in a polymorphic call.
Most object-oriented languages do not attempt multiple-inheritance. The literature is full of elaborate explanations why. This is sad. Eiffel demonstrates that multiple inheritance need not be difficult or complex, and it can also yield some quite practical results.
Eiffel provides an implementation of multiple inheritance which minimizes the adverse effects of name collisions and repeat inheritance complications. As is typical in Eiffel, the solution to one problem helps solve another problem. In Eiffel, a name inherited from an ancestor may be revised in a descendent using a rename clause. Eliminating name collisions then merely involves giving a new name to one or both of the colliding features. The feature is unaffected, except that it is known in the renaming class and any descendents of that class by its new name.
Supposing we have a class named SOME_OTHER that inherits two entirely different features both called put from two ancestors named FIRST_CLASS and BOWSER:
class SOME_OTHER inherit FIRST_CLASS rename put as first_put end; BOWSER rename put as bowser_put end; ... end
then in some client class we may have feature what_now:SOME_OTHER
-- We may invoke the feature -- named put from either of its -- originating classes what_now.first__put(this); what_now.bowser_put(that);
Repeat inheritance is only slightly more complex. In the simple case, repeat inheritance is just a by-product of the class inheritance structure you have chosen. Perhaps some of the classes inherited from the class library have common ancestors—this is almost certain. Your responsibility is easy: do nothing. The compiler eliminates the duplicates, and your class has only a single copy of each inherited feature, regardless of how many different ways a feature might come to be present.
In the less common situation, you might want two copies of a feature, for instance put, from an ancestor. A class fragment exhibiting this situation might look something like this:
class SOME_OTHER inherit FIRST_CLASS rename put as first_copy select -- Resolve an ambiguity. first_copy end; FIRST_CLASS rename put as second_copy end;
The select clause serves to resolve an ambiguity. Suppose you reference an object of type FIRST_CLASS and you happen to invoke a feature known in FIRST_CLASS as put.
SOME_OTHER inherits FIRST_CLASS twice, and because of the renaming, there are two possible answers to the question, “What is the name of put in SOME_OTHER?” The following code fragment illustrates:
-- Declare a reference of type FIRST_CLASS -- then attach an object of type SOME_OTHER, -- a descendent of type FIRST_CLASS, using a -- creation procedure of SOME_OTHER called "make" this:FIRST_CLASS; !SOME_OTHER!this.make; -- When you try to invoke put, -- without select it is not clear what you mean. -- Could mean first_copy, could mean second_copy. this.put;
The select clause removes the ambiguity by saying, “When invoking this duplicated feature under its ancestral name, select this copy.” Note that Eiffel brings a thorny problem, repeat inheritance, to the resolution you might hope for. Duplicates are simply eliminated, with no further intervention. If you wish to duplicate-a much less common situation—you can do this using quite simple syntax. Finally, features of the same name that are distinct may be renamed so that both are available, or the unwanted feature may be undefined. pb In each case, the mechanisms provided are simple and local to the class where the problem arises. No revisions to ancestors are required. This is no accident. A major thrust in the design of this language was to eliminate the occasions for revisions to ancestors. Reuse is served here by localizing any adaptations required by repeat inheritance and name collisions in the class where they are encountered. The ancestors are not broken, so they require no fixing. If they are not fixed, they will not have bugs introduced, and other clients or descendents of the ancestor classes will not be affected by changes, bug-inducing or otherwise, that might otherwise be required in the absence of suitable means to resolve conflicts in the descendent.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Devuan Beta Release
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The US Government and Open-Source Software
- The Humble Hacker?
- The Death of RoboVM
- BitTorrent Inc.'s Sync
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- AdaCore's SPARK Pro
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide