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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
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