Re: ambiguous inheritance question

[Randall.Smith@Eng.Sun.COM (Randy Smith)]

> 
> given an inheritance hierarchy as below:
> 
>                A
>               / \
>              B   C
>               \ /
>                D
> 
> where B and C are parents of D, and A is the parent of B and C,
> 
> If A defines slot m, and B defines its own version of slot m, if you send D 
> the message m, you get an ambiguous selector error (as expected).
> 
> How about if D got the m in B, because it does override the one in A,
> after-all. What I mean is that the m in B overrides the very same slot m that D
> inherits via C. If it was a different m that it was overriding I'd be totally
> happy with an ambiguous selector error.
> 
> What do you think? Would the proposed scheme invite obscure bugs? Would it
> be difficult to understand? You may think that this sort of situation doesn't
> occur often enough to be a problem - maybe true - but dispite that, what do
> you think?
> 
> Ivan.
> 
> 


I believe this is what we call "unordered up to (but not including)
join" semantics.  I think Craig Chambers, who was with the Self group at
the time we were rethinking MI, was an advocate for putting this style
of MI in Self.(comment Craig?)

It's something we talked about, and it does have the advantage of
allowing many cases (but not all cases, I think) of "data parents."

There are still other concerns about data parents ... Self used to have
them many years ago, but they were kind of nice in some ways.

Anyway, the thinking was more on the side of radical simplification:
making MI as easy as possible to understand.

However unordered up to join is maybe not all THAT complicated, and
because it allows this useful data parent thing, maybe it is a good
idea.

Instead of data parents, today we "copy down" at creation time, and that
yields its own set of complications.

Interesting that you hit upon this idea!

	--Randy

P.S.: In unorderd up to join, this below would be an error, whereas in the
old days, B and C could be given different priorities, and therefore 
data parents, who often appear in graphs like this,
were easier to support.

                          A(m)
                         / |
                        /  |
                       /   |
                     B(m)  C(m)
                      |    /
                      |   /
                      |  /
                      | /
                      D