On Tue, Mar 2, 2010 at 3:00 PM, chromatic <[email protected]> wrote: > 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.
There's really only one find_method VTABLE, but Object uses it to perform the very specific lookup of the method in the MRO of the associated Class. This has a number of problems, as I enumerated in the previous email: Object requires intimate knowledge of the internals of Class, which means we can't use anything but Class (and, as a hack, PMCProxy which has been specifically crafted to be isomorphic to Class) in an MRO. This includes subclasses of Class. Granted we could fix the subclass issue with some hackery, but we would still be limited to Class and it's subclasses in an MRO only. This also igores the idea that we can't really lookup whether a particular type supports a particular method without instantiating an object of that type to search. This isn't always possible for objects with a destructive or state-changing initialization routine. Adding "yet another VTABLE" isn't so much of a problem when you consider that a very large amount of them have been removed recently, and their are tickets to propose removal of others. A policy "don't add good new things, because we've already added far too many bad things" is a lousy policy. If space is a concern, I could come up with a half-dozen other VTABLEs which are used far less often and to far less effect than a find_class_method VTABLE would be. > 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. And how are we looking up the method in the invocant's Class? we can't use find_method on Class, because Class is a type itself and the Class type has it's own methods that can be found and invoked. We can do what we are doing: blatantly break encapsulation and require intimate knowledge of the internals of Class, which would prevent ever having another type of object that stores methods, but that seems like a lousy solution that imposes a steep penalty all for the benefit of saving space for a genuinely useful pointer. > 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". The super() issue is only a small part of it, and you're right that there are a dozen ways we could patch a super_method opcode into the system as it is now. My idea about passing an iterator to the find_class_method VTABLE to support this was just an off-the-cuff idea and is hardly worth arguing about. The real benefit to the new vtable is properly encapsulating the interface to this PMC and allowing people to plug in their own metaobjects as necessary. Again, are we going to force everybody in every HLL to use our metaobject model without modification just because we want to save a pointer? > There's no additional VTABLE necessary, and we respect the metaobject protocol > that says that Classes are also Objects. Not necessary, but I think extremely beneficial. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
