Hi,
One of the things we need to specify in PDD 15 is method resolution order.
--
BACKGROUND
The MRO, short for Method Resolution Order, is the order in which we
search classes in an inheritance hierarchy when looking for attributes
or methods to call. The MRO is represented as a linearization of the
hierarchy - basically, a list of classes in the order that we should
search them when looking for an attribute or method.
THE NEED FOR PLUGABILITY
Different languages may have a different MRO. Python since 2.3 and Perl
6 by default use C3. Perl 5 used something else. Therefore, we need
computation of the MRO to be pluggable.
It's clear that we need to have MRO pluggable by class, since classes
will be written in many languages. More interesting is that, for Perl 6,
we also need to override the MRO on a by-method-call basis - you can
change the dispatch order at the call site! While in Perl 6 attributes
are not an issue in this (since they are private to a class and only
have public accessors which are methods), for completeness we may want a
way to specify the MRO for an individual attribute lookup too.
BEING PLUGGABLE IS EASY!
Through the MetaClass of any class, you can get a list of its immediate
parents by calling the parent method, and so on up the tree. This means
that computation of the MRO can be completely abstracted away from the
internals of the class/object system. It also means there's no reason at
all why a PIR sub cannot be called to compute an MRO.
Obviously, for performance reasons we should implement computation of
some of the most common MROs directly inside Parrot, but those also
should only work through the parents method available in the MetaClass PMC.
CLASS MRO
The MetaClass PMc should get two extra fields:
* MRO type - a value from an enum like...
0 - C3
1 - Custom
2 - Preorder
* If MRO type is 1 (Custom), a reference to a Sub PMC to compute the MRO.
We compute the MRO at the time when the class is first instantiated
(rather than upon the addition of a parent) - note that adding a new
parent to an already instantiated class will clone the class, name
binding the new modified class to the name of the original class, but
not affecting any existing instances of the class.
Additionally, the MetaClass PMC will get an additional method for
setting the MRO. Optionally, we could allow a language to specify its
own default.
METHOD CALL MRO
Normal method discovery using the MRO of the class will be implemented
inside of the find_method v-table call. An additional op that enables
the finding of a method using a different MRO would be required.
Attributes, if we wanted to allow a different MRO on them, would have an
analogous implementation.
--
Hope that this makes some kinda sense - feedback would be *very* welcome!
Take care,
Jonathan
