Re: Objects, finally (try 1)

[Dan Sugalski]

At 10:37 AM -0500 1/10/03, attriel wrote:

 > On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:

 #10 We do MI, but we don't instantiate a class' attributes multiple
   times if its in the hierarchy for a class more than once. If it is,
 the leftmost instance is real, the rest are virtual

My only question here is:  What is leftmost?  Is that the same as "closest
to the actual class we're looking at" or is it "first time it appears in
the inheritance structure, and thus the furthest from the relevant class"
? (or something else entirely?)

For attributes it doesn't matter. For methods, well, I'm not sure whether a leftmost depth-first insertion is right or inserting it somewhere else is better. I expect Damian Has The Answer. (Or, if I remember from the last time I asked, several answers of which there wasn't a clear Best Answer)

 > This will mean we can't support Eiffel, which allows repeated real

 inheritance of the same class. It does this by allowing renaming at the
 feature level (thats attributes and methods in perl) when inheritance is
 declared. Repeated inherited features are shared if they keep the same
 name (and they really are the same feature), or split if they don't.

I'll admit to never having gotten to looking at eiffel, just hearing about
it from some other folks ...

But what is the point of explicitly inheriting from the same class
multiple times?  I mean, sure, if it's in the inheritance tree multiple
times, fine, but then you ignore most of them generally; what benefit/use
comes from having it actually be in the tree multiple times as distinct
entities?

If you do redispatching of method calls it makes sense, since if there are enough redispatches you may end up redispatching to one class' method more than once because it's in the tree more than once, in which case you'd want to get the correct set of attributes, as each instance of the class in the tree should have a separate set of attributes in that case.

(I could, of course, be horribly wrong, had I stated a firm opinion rather
than requests for more information :)

Ah, go for the bold statement. People are more likely to refute an error that way. :)

Also, as I pointed out a little while ago, this is the proposal for the base perl6/ruby/python object scheme, but there's nothing that forbids transparent interoperability with a different object scheme.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk