Warp wrote:
>   I think that a class for which it doesn't make any sense to have something
> like "ToString()" it would be bad design to force it to have it after all.

I think there's a reasonable "ToString()" for every class. There aren't many 
routines in Object, but the ones there are pretty universal. "What type am 
I?"  "What code defines this type?"  "What's my address?"  Stuff like that.

In the CIL, I haven't memorized exactly what's there, and some stuff like 
that might be in other libraries. But it's usually pretty universal.

>   I wonder if it would make garbage collection more complicated because now
> you can have references pointing to the middle of an object rather than the
> beginning (and it may be the *only* reference pointing to that object, so
> the object must not be collected as long as this reference exists, but it
> may be more complicated for the GC engine to know this).

For something managed, I think that would be the wrong way to implement MI. 
It's still just one object, even if it inherits data and code from multiple 
classes.  For example, Python has MI and doesn't have pointers into the 
middle of objects.

You could also do it as a sort of "automatic delegation", where each of the 
multiple parent classes is represented as a separate object on the heap, for 
example, and the child class delegates all the non-overridden calls to the 
parent class. In this case, you'd have no significant overhead if the parent 
class contributed only code (as the JIT would optimize out the additional 
redirection on first invocation).  You might be able to also jit-compile the 
multiple classes and rearrange their code to use different offsets for the 
instance variables when you load the CIL code for a class that has multiple 
parents, for example.

The only reason C++ carries pointers to the middle of objects (as far as I 
can tell) is that they can't rewrite the object code to use different 
offsets in the child class compared to the parent class, and of course 
because it can since there's no memory compaction.

>> Where have you found multiple inheritance particularly useful in C++?
> 
>   Wherever implementing multiple interfaces (or a base class and one or
> more interfaces) is useful in any OO language, in cases where it would
> actually be useful if the "interface" methods could have default
> implementations, or if it would be useful if the interface provided
> auxiliary methods for the derived class to use.

So the "mix in" sort of inheritance. OK.

>   The problem with "interfaces" is that they are not *helpful* at all.
> The don't offer any functionality, any default implementations or any
> data. These "interfaces" could often become a lot more helpful if they
> actually offered something for the derived class so that it doesn't have
> to implement everything from scratch every time.

That would definitely be useful, yes.  Maybe a later version will add it.

Probably right after the folks working on Java do. ;-)

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

Post a reply to this message