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 :)
