find_method changes and proposals

[Andrew Whitworth]

On Sun, Feb 28, 2010 at 11:52 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> If I'm completely misreading the proposal, then I apologize for
> this message and hope you can clarify.

I should have been more clear. I was pointing out some problems and
suggesting a few possible ways to fix them.

If we look at the find_method vtable, it does the operation "find a
method on SELF, where SELF might be the invocant". This is limited
because the object is forced to walk it's own MRO, cannot delegate the
search to individual objects in the MRO and therefore needs to have
intimate knowledge of the internals of each type of object that
appears in the MRO. If you look at the code for Object.find_method,
you see that it breaks encapsulation of the Class PMC, and is going to
have fundamental problems handling objects that are not Class objects
in the MRO, PMCProxy seems to mostly survive this nightmare becaus it
is explicitly designed to use the Parrot_Class_attributes structure to
hold its data in a way that is transparently identical to the way
Class stores it, but this is a hack.

If we have items in the MRO that are not Class or PMCProxy PMCs, (and
I think we can both imagine other things we would like to include in
the MRO like Roles, Mixins, etc), Object fails to find any methods in
them.

What I suggest we do is add a new vtable that does the operation "find
a method in SELF, where SELF is a metaobject in the MRO of the
invocant". This would allow us to properly delegate the search to the
metaobjects without preventing Class and friends from having their own
instance methods available through find_method. This would also allow
us to transparently use any type of object we want in the MRO, because
those objects would know their own lookup procedure. An immediate use
I could find for such a mechanism would be implementing an AUTOLOAD
mechanism on a per-type basis. Or, we could inherit from an object
defined with a different MRO algorithm, or the ability to add mixin
methods at runtime, or implement something like "extension methods" in
C#.

My suggestion for the new vtable takes an iterator to the invocant's
MRO array as an argument, so objects can keep track of the search
recursively, to avoid repeated searching of common parent types. This
would have the added benefit of allowing us extreme flexibility to
modify the MRO on a per-call basis if needed, or to allow special
objects to modify the remaining MRO if needed (search only N deep,
search additional parents, etc).

So my biggest proposal is to add a new vtable to suppliment
find_method but to delegate responsibility to the metaclass.

--Andrew Whitworth