[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ambiguous inheritance question
> From Bay.Chang@Eng.Sun.COM Tue Jan 31 20:42:12 1995
> Content-Type> : > text>
> From: Ivan Moore <email@example.com>
> To: firstname.lastname@example.org
> Subject: ambiguous inheritance question
> Date: Wed, 25 Jan 95 19:26:16 GMT
> Dear Self interest group,
> What are peoples opinions on the following:
> given an inheritance hierarchy as below:
> / \
> B C
> \ /
> 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?
I proposed such a "partial-order-based" MI overriding rule for Self a long
time ago. I think the argument against it is that you no longer can view
each parent (B & C) separately, but only in combination. I.e., to understand
method lookup for D, you have to examine D's entire inheritance hierarchy;
you can't just send lookup to each of the parents independently and then
combine the results in a simple way.
But I still like this more global semantics for MI, and I've included it in
the Cecil language I've been working on. We've written 50K lines of Cecil
code in our Cecil optimizing compiler, and I think our experience with this
MI semantics has been quite favorable. At least, it's always made sense to
me how method overriding worked, and I can't recall ever being bitten by a
bug as a result of this semantics.