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.
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
|Pandas||Aug 17, 2016|
- Happy Birthday Linux
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- New Version of GParted
- NVMe over Fabrics Support Coming to the Linux 4.8 Kernel
- All about printf
- Tor 0.2.8.6 Is Released
- Tech Tip: Really Simple HTTP Server with Python
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide