Classes as Packages (was: Harvesting infrastructure)

Tim Rowledge tim at sumeru.stanford.edu
Mon Nov 18 18:38:13 UTC 2002


> > And anyone that starts going on about multiple inheritance is looking for
> > a visit from one of the four horsement of the apologists. :-)
> 
> I think this is a myth of multiple inheritance.  I think it can be tamed
> and used effectively.  See above.
Lots of people have tried to convince of that in the last twenty years
and so far not a one has made a good enough case to change my mind. It
is certainly possible you may be the first but don't hold your breath
too long!

One of the classic old claims for MI was along the lines of -
well, I have implemented Toy and Truck and now I want a toy truck so I
should be able to inherit from both. Yippee, it's obvious! BZZZZZZ.

Firstly, like many occasions where people make claims congurent to this,
it's a bad example. Truck, if implemented in any serious manner, will
have a great deal of state and behaviour that is nothing whatosever to
do with toy trucks. Do toy trucks need to know about, say, service
schedules, fuel consumption, tyre pressure et al.? I doubt it. It's a
bad mix.

Secondly, I've never yet been convinced that any proposed implementation
of MI can handle the tangle of possible inheritance upstream. Where and
how should one decide which of the possible upward paths to follow? If
following one path leads to a DNU should you try another? And another?
I think it is easy to see a pretty nasty O(something horrible) problem
here. How would one specify which path to use it if it supposed to be
decided by the programmer? The old ST-80 MI experiment used munged
selectors, something like 'self truck.size' which looked 'orrible. And
probably allowed something like 'self number.wibble' whcih wuldbe
nonsensical.

Thirdly, it always seems more plausible to me to use
composition/delgation. ToyTruck would be a little better if implemented
as having a toy-ness ivar and a truck-ness ivar and then _using_ them
rather than inheriting them. I imagine that this maps onto Traits
reasonably well from my current understanding. I would concur however
that making it possible to subclass traits would be (probably) useful;
but let's not go into whether traits should have trairts, at least just
yet.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- He donated his brain to science but they made an
early withdrawal.




More information about the Squeak-dev mailing list