> =head2 Hierarchical C<SETUP> calls
>
> It is proposed that when an object is blessed, I<all> of the C<SETUP> methods
> in any of its base classes are also called, and passed the argument list
> appended to the invocation of C<bless>. C<SETUP> methods would be called
> in depth-first, left-most order (i.e. ancestral C<SETUP> methods would be
> called before derived ones). Any given C<SETUP> method would only be called
> once for the same object, no matter how many separate paths its class might be
> inherited through.
As a minor change, I would like to propose it do depth-first, RIGHT-most
order.
This change could make a big difference in making things work better than
they would otherwise. A function call, as it travels through the
inheritance tree, goes depth-first, left-most order.
Let's say you have two superclasses that you absolutely need to
combine. For this example, we can do:
Mammal
/ \
Cat Dog
\ /
CatDog
Now, as I search the inhertitance tree for play_noise, it'll necessarily
find the cat's sound before it find's the dogs. (I'll ignore the problem
of dog overriding a function in Mammal, which never gets called...but that
occurs in every multipl-OO implmentation I've seen).
Now, CatDog can define it's parents as Cat,Dog, or Dog,Cat, which are very
different in which parent this mutant offspring resembles more. Let's say
it does Cat,Dog, because it's mother was a cat shaped the mental
upbringing of this offspring, causing it to act more like a cat than a
dog.
The initialization of the parent-hierarchy, imo, should be done with Dog
first, and Cat second, so that Cat can 'override' any such things that Dog
defines/provides in the constructor. Because Cat gets the final
say in if a given function gets called, it should get an overriding say
over Dog's initialization/constructor to balance that out.
> =head2 Hierarchical C<DESTROY> calls
>
> It is further proposed that when an object's destructor is invoked, all
> inherited destructors would also be invoked, in depth-I<last>, right-most
> order. Again, each C<DESTROY> for an object would be called exactly once,
> regardless of how many different paths it is inherited through.
And assuming the SETUP calls go depth-first, right-most, the DESTROY calls
should go depth-first, left-most.
I suppose one could argue that having a common base class is what causes
all these problems, and it just leads to confusion, etc, etc. I agree. I
really am not a big fan of multiple-inheritance, and perhaps if one were
to implement Damian's NEXT proposal in another RFC, we might be able to
remove the need for multiple-inheritance altogether, and remove the
ability to create so many strange, twisted, confusing situations.
But, if multiple-inheritance is supported, then I'd like the
constructor-chaining to work and help out the poor guy trying to mix
matter and anti-matter, so he can at least contain the resulting
explosion. :)
Of course, this may just be my particular view on the situation, and
there may be equally, if not more valid reasons for doing it another way.
Mike Lambert
