On Tue, Mar 2, 2010 at 4:32 PM, chromatic <[email protected]> wrote: > 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.
I don't see how that helps at all. The code to access the internals of Class would still not be in class.pmc, which means that Class *isn't* encapsulated, and we can never use a type as a metaobject or method storehouse that isn't a Class PMC or an item that is painstakingly isomorphic with it. Instead of providing a single interface function and delegating the search out to the objects that implement the MRO, we're still using code external to Class to walk the MRO in a way that only supports Class. > 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. Multiply entities? Asking Class to manage it's own method lookup as opposed to creating some entirely new mechanism to perform the lookup? > 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. First, I would love to see an example of a compiler providing it's own Class and it's own Object. I'm not even certain how that would work internally. Both the newclass and subclass opcodes create a non-HLL-mapped enum_class_Class PMC. I concede that it is strictly possible for us to create our own metaobject type and use that with the new opcode to instantiate instances of that type, but we would lose a lot of the infrastructural support that Parrot provides to Class. For instance, if the class wasn't registered and a VTABLE wasn't created for the type, we would not be able to use Parrot_pmc_new(), and would never be able to HLL map our type for core to use. Maybe you could hack this support together IF you wrote your metaobject in C instead of PIR and completely violated encapsulation of the Parrot API, but I would hardly advertise this as an alternative because it would be so hobbled. > 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. There are two ways to look up the method in an arbitrary metaobject: Either call an API function, or have a priori knowledge of the object's internals. As a counter-example which would be impossible using the current Class interface, consider something akin to Perl5's AUTOLOADER. AUTOLOADER cannot produce a hash of available methods on demand, because those methods are not necessarily loaded into the VM until explicitly searched for by name. I can tell you that Matrixy development is essentially blocked because of a lack of a good AUTOLOADER-like feature. That language relies on that mechanism heavily and there's no good way to implement it without having to wrap every single function call in a heavy-weight dispatcher, which is highly suboptimal. > 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. If space isn't the option, then I have no idea what your objection is. Yes, the way default does method lookup now is broken. Instead I suggest we give PMCProxy an interface function and delegate the lookup to it. PMCProxy knows what methods are available because it's going to contain them all. default.pmc should throw a not found exception when find_method is called on it. > The same way we look up methods in Classes now. A Class has a Hash which > contain methods indexed by name. Again, AUTOLOADER. A complete hash might not be available. In any case, how do we get that hash? Direct attribute access (which limits implementation) or a VTABLE? --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
