Warp wrote:
>   Then don't make every class inherit from a common base class. Interfaces
> don't, so why should classes?

Because then you can put routines on that common base class that are common 
to every class, like ToString() and Equals() and HashCode() and such.

>   If you really want must have classes inherit from Object, then simply
> allow interfaces to have member variables and function implementations.
> Then you'll have full-fledged multiple inheritance without diamond
> inheritance.

That certainly sounds like a good idea to me. :-)

Of course, the way it works now is that an interface doesn't actually change 
what's in the class. It's more a promise that the class implements a 
particular set of routines. So it's not unlike a pure abstract class. If you 
already implement a routine called Run, whether you inherit from Runnable 
doesn't change what's in your class, only what's in your metadata. So adding 
that feature isn't as much of a no-brainer as it might otherwise be.

On the other hand, maybe it wouldn't be a bad idea to have inheriting from 
an interface actually insert code into your class as necessary. It would 
certainly be a trivial way to make that work in C# at least, if not in other 
languages based on the CIL.

Where have you found multiple inheritance particularly useful in C++? Eiffel 
uses it all the time to good effect in its data structures, but I've never 
really seen anything in C++ that used it, in part maybe because of the way 
it's implemented in C++ with classes nested inside other classes and such 
and not being able to inherit from basic types.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling together,
   but to different destinations.

Post a reply to this message