MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: [MC] Multiple Inhertiance

On Wed, 10 Apr 1996, Matthew Sanderson wrote:

> He said 'parent', not 'ancestor'. There is no need to select which
> _parent's_ verb you are going to pass() to if there's only one parent.
> With arbitrarily many parents pass()ing introduces a real problem: if
> several parents define a verb with the same name (a very likely scenario),
> which one do you pick?
> The point stands.

C++ uses the scoping operator for this We could do the same thing here --
if a verb wants to pass() to a specific ancestral version of itself it 
would specify obj::(verb)()... which would generate an error if obj was 
not an ancestor of the object, or verb was not the same as the verb running.
Calling in this manner would preserve the usual things that pass() does 
-- specifically, the value of "this".

> Relying on the order of objects in .parents for this choice seems to me to
> be extremely iffy...

The real problem is that it's not flexible enough.  What happens if I want
most of the functions from one inheritance tree, and some from another? 
If pass() functions the same way as normal verb calls, I have, as you
point out, no way to get at the other versions; I can't even write a
version on the descendant that just pass()es to the version I want... 

Or, consider the version of multiple inheritance I propose a couple 
messages ago -- where ambiguity is simply not allowed.

> Also: I don't see why you think chparent() becomes obsolete under a
> multiple-inheritance server. This would mean that if my generic foo has
> parents A, B, C, ... Z and I want to make it only a parent of BAZ (perhaps
> I'm recycling it), I would have to remove_parent each of the 26 parents,
> then add_parent BAZ. Ick.
> chparent( {[parent, [parent, ...]]} ) would seem much more intuitive and
> efficient to me...

But a chparent() call like that would effectively have to do 
remove_parent for those not in the new list, and add_parent for those not 
in the list -- so it's no more *efficient*.  It's just more convenient, 
and as such, it's more fit for $ancestry_utils.

  --Chris                           cunkel@engin.umich.edu
    ResComp Network Support Technician, Bursley Hall
    "Invisibility is in the eye of the beholder."
    Home Page: http://www-personal.engin.umich.edu/~cunkel/
Follow-Ups: References:
Home | Subject Index | Thread Index