find_method changes and proposals
wknight8111 at gmail.com
Wed Mar 3 01:03:23 UTC 2010
On Tue, Mar 2, 2010 at 4:32 PM, chromatic <chromatic at wgz.org> 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
> 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?
More information about the parrot-dev