On Sun, Feb 28, 2010 at 11:52 AM, Patrick R. Michaud <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
