On Friday 11 October 2002 11:32 am, Hans Beck wrote:
> Hi,
>
> I'm using squeak for prototyping our LCD measurement system
> software. From time to time, some colleagues look at my display and
> are astonished ;-)) But they are c++ freaks, and if we discuss
> about the usability  of squeak for prototyping, always there comes
> the argument of lacking multiple inheritance.
>
> So because I'm not a theoretican for computer languages but  I
> suppose there are a lot very good guys on this list, I would ask
> the community, how far multiple inheritance is really needed, or is
> it bad or what ever ? (Looking from a more or less theoretical
> viewpoint of object oriented concepts ) ?

=46rom my point of view (having done quite a bit of C++), the only real=20
advantage that C++'s multiple inheritance has is that it lets you=20
share code relatively easily between classes that share an interface.

And that's not often that useful, since the implementation of those=20
methods that get mixed in often has to differ slightly. So you have=20
to re-factor to the point where you can use MI. This refactoring=20
isn't because it's actually necessary, it's because of the=20
limitations of C++'s typing system.

There have been a number of hacks that have simulated MI through the=20
years.

Of course, Smalltalk doesn't need inheritance at all to provide the=20
kind of polymorphism that you get in C++ with MI. All that's required=20
is for two objects to understand the same messages. What they do with=20
those messages is their business. They may have corresponding methods=20
or they may handle them somehow with doesNotUnderstand.

Given (currently non-existent) tool support in Squeak:
If you're careful, you could probably share code between unrelated=20
classes by editing the method dictionary, but to do this safely you'd=20
need tool support (making sure, for instance, that like-named=20
instance variables are in the same slot for those copied methods). Or=20
you could track copies of code so that when a copied method is=20
modified, it gets compiled for every class that includes it. It's=20
unlikely that you could change the object model or the compilation=20
model so easily in a C++ environment.

But more generally (with the tools at hand), we just tend to do what=20
Java programmers do: that is, when two classes share an interface and=20
are not related via inheritance, we write the corresponding methods=20
for both classes. Which may be something as simple as copying the=20
code (which of course means that there is a bit more potential for=20
missing a fix later).

--=20
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE