Here are some examples from Object Oriented Software Construction (Second Edtion), Chapter 15 (Multiple Inheritance):
* Simple multiple inheritance: class PLANE ... class ASSET ... class COMPANY_PLANE inherit PLANE ASSET ... or class TREE [G] ... -- Parametric Polymorphism class RECTANGLE ... class WINDOW inherit TREE[WINDOW] RECTANGLE ... * Renaming: class WINDOW inherit TREE [WINDOW] rename child as subwindow, is_leaf as is_terminal, root as screen, arity as child_count, ... end RECTANGLE ... * Page 548, "Unobtrusive repeated inheritance": Cases of repeated inheritance [...], with duplicated features as well as shared ones, do occur in practice, but not frequently. THey are not for beginners; only after you have reached a good level of sophistication and practice in object technology should you encounter any need for them. If you are writing a straightforward application and end up using repeated inheritance, you are probably making things more complicated than you need to. * Redundant inheritance: class A ... class B inherit A ... class D inherit B A ... -- Forgetting that B inherits from A In Eiffel, the default sharing semantics for multiple inheritance means this misstep doesn't cause weird things to happen. * Other weirdness class DRIVER ... -- violation count, address, etc. class US_DRIVER inherit DRIVER ... class FR_DRIVER inherit DRIVER ... -- Ah, France! class US_FR_DRIVER inherit US_DRIVER rename violations as us_violations, ... FR_DRIVER rename violations as fr_violations. PLEASE NOTE: I'm not a fan of this example. But, it comes from the book. I'd be more likely to model this as DRIVER has-a SET of LICENSEs keyed-by AUTHORITY, where the LICENSE has stuff like licensed address and violation count, etc. But, then, my thinking and modeling habits tend toward the dynamic, and Eiffel tends toward the static. The implications of continuing the pattern of this example in the face of a larger set of authorities (countries) is, well, explosive (speaking combinatorically). In the face of a dynamic set of authorities, its unworkable. Anyway, I know that the Eiffel libraries make plenty of use of Eiffel's inheritance and assertion mechanisms. I don't know how often these more complicated situations arise in practice. The point is, Eiffel does have these mechanisms defined and they are expected to be available, and possibly required just to build mundane applications that use the standard library. Regards, -- Gregor "attriel" <[EMAIL PROTECTED]> 01/10/2003 10:37 AM Please respond to attriel To: <[EMAIL PROTECTED]> cc: Subject: Re: Objects, finally (try 1) > On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote: >> #10 We do MI, but we don't instantiate a class' attributes multiple >> times if its in the hierarchy for a class more than once. If it is, >> the leftmost instance is real, the rest are virtual My only question here is: What is leftmost? Is that the same as "closest to the actual class we're looking at" or is it "first time it appears in the inheritance structure, and thus the furthest from the relevant class" ? (or something else entirely?) > This will mean we can't support Eiffel, which allows repeated real > inheritance of the same class. It does this by allowing renaming at the > feature level (thats attributes and methods in perl) when inheritance is > declared. Repeated inherited features are shared if they keep the same > name (and they really are the same feature), or split if they don't. I'll admit to never having gotten to looking at eiffel, just hearing about it from some other folks ... But what is the point of explicitly inheriting from the same class multiple times? I mean, sure, if it's in the inheritance tree multiple times, fine, but then you ignore most of them generally; what benefit/use comes from having it actually be in the tree multiple times as distinct entities? I'm just wondering there ... But if it's renaming the structure anyway, wouldn't it still be possible with the single-MI structure that dan proposed? as in, if B inherits from A and then C inherits from A and B directly (and assuming there's a need to separately retain the individual inheritance directions), wouldn't the compiler then say that B inherits from A and C inherits from A2 and B, to retain them both in the parrot? --attriel (I could, of course, be horribly wrong, had I stated a firm opinion rather than requests for more information :)