Re: closures for GOOPS privates

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Clark McGrew <mcgrew@ale.physics.sunysb.edu> writes:

> Personally, I'd to see a bike with a piano mounted on back (with
> somebody else to pedal each).  Even still, a "piano bike" should
> probably inherit from "bike" and contain a "piano", or the other way
> around.

Umm.  I assume you don't have two heads, one from your father and
one from your mother. :)  Inheritance is logical concept.  You inherit
features, not parts.

The class "piano bike" has basically two inherited features: You can
move around with it and you can play songs while moving around.
Accidently two differend features have the same name ("pedal") so that you
must rename one of them.

If you want to create a bike with a piano mounted on its back then
you don't need inheritance.  Just take the piano module and put
the bike in it.  But inheritance is not aggregation.  The module system
handles physical aggregation while the OO (type) system handles the
logical structure.

The duckbill for example has two features with the name "fortpflanzung"
(english propagation ?).  Two differend features with the same name.

Another example would be the class fruit-color.  If you create the
auxiliary classes fruit and color in a module to combine them to the
exported class fruit-color, you must rename the feature "orange".


> I meant "conflicting" in the most practical way... They both have a
> pedals that do different things and you must rename features to
> inherit from both classes.  To my mind that means there is an
> ambiguity and the OOA needs work.

It would be a bad idea to step from the design or coding phase back into
analysis and change everything just because the implementation language 
is broken.

If you want to support multiple inheritance you have to deal with the
fact that two differend inherited features may have the same name.


Instead of renaming a feature one could use another approach: You
don't resolve such a conflict but search for and call the first
appropriate method.  Whenever you want to access the second (shadowed)
method you have to explicitly change the order in which the parents
are listed.



Jost