On Sunday 28 February 2010 at 09:31, Andrew Whitworth wrote: > 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.
Instead of adding yet another VTABLE, how about fixing find_method? There are two find_method implementations in the system, one for PMCs and one for objects. One has a method cache. The other has a wildly different method cache that may or may not work. Both have to walk MROs, even if they do it in wildly different ways. Granted, we can't unify them until we unify method storage (TT #389), but once they're unified, the path can be the same: get the invocant, get the class of the invocant, and then look up the method in the invocant's class. If we do that right (probably with helper functions in src/oo.c), we should be able to look up methods for classes further up MRO for almost free, as we already have that infrastructure in place. A hypothetical super opcode or super method could become "Look up the method of this name one step higher in the MRO of the current class". There's no additional VTABLE necessary, and we respect the metaobject protocol that says that Classes are also Objects. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
