Re(2): ambiguous inheritance question

["David Ungar" <david.ungar@Sun.COM>]

By the way, I'm intrigued by a different style of programming,
but unfortuneatly our VM doesn't quite support it efficiently enough
to convert over the whole system.

In this style you lump together methods and data slots,
and use data parents (with single inheritance!) instead of copy-down.

so a point has:

parent, +, x, y in it.

and a colored point has

parent* <- aPoint
color <- ...
<other methods>

in it.

The catch is that the parent slot of colored point
causes a bunch of inefficiency today, otherwise
I would be doing it in a big way.
But there are ways to make this work well (
one was suggested by Craig a long time ago and I haven't
forgotten).

I really think it would be better than what we have.

Maybe for Self 5.0, if and when....

Dave


 ------ From: Randy Smith, Tue, Jan 31, 1995 ------ 


> 
> 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