On Tuesday 02 March 2010 at 13:20, Andrew Whitworth wrote: > 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 is the primary problem with the *implementation* of find_method in Object. All of these problems are problems of implementation. Move the code that performs the lookup of the method out of Object into src/oo.c (or possibly src/oo/class.c) and, all of a sudden, it's not violating the Class PMC's encapsulation any more. You don't need to multiply entities to solve the problem that some code is in the wrong file. You only need to move that code to the right file. > 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. Any HLL or project which wants a different metaclass already has a great way to store methods in a different fashion; provide their own Class and Object. How instances of those Class and Object PMCs respond to find_method is up to them. You can't instantiate an Object without going through Class in Parrot anyway; they're already coupled. A metaobject protocol implies that. > 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. I don't see why not. I'm suggesting we add a C function which can look up a method on a given class. We can expose that at the PIR level in any of several different ways. > 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. Space is not a primary concern. Correctness is. The bicameral approach to storing methods between the default PMC and the Class PMC is a huge problem. Once we fix that, entertaining other approaches is much more feasable. > And how are we looking up the method in the invocant's Class? The same way we look up methods in Classes now. A Class has a Hash which contain methods indexed by name. > 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? That's not my motivation at all. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
