find_method changes and proposals

Allison Randal allison at parrot.org
Thu Mar 4 16:32:42 UTC 2010


Andrew, I like what you're working toward. This particular solution 
isn't quite right for Parrot, but it's a good exploration.

- Class, Object, and PMCProxy are a group of PMCs that work together to 
implement a generic object system. Because of this they are allowed 
thinner encapsulation boundaries between each other. That said, we could 
improve on the encapsulation here by calling the 'inspect_str' vtable 
function for "methods" rather than directly poking into the Class's 
struct. (The code for 'find_method' was written before we added 'inspect'.)

- Systems that want a completely different object model need to subclass 
or polymorphically substitute their own object type. The built-in object 
model needs to be generic enough to support alternate object models, but 
won't necessarily support inheritance between all possible object 
models. (That is, we'll make it possible to write your Class, Object, 
Prototype, etc to work with Parrot's base object model, but we can't 
make it impossible to write object models that are incompatible.) We 
need to do some work on defining the API for object models, answering 
the question "What is my object model *required* to support to interact 
with Parrot's base object model?" (e.g. to interact with the POM, you 
must support a "methods" lookup through 'inspect_str'...)

- 'find_method' looks up instance methods on Object, and class methods 
on Class/PMCProxy. That's intentional, a class in a metaobject protocol 
is itself a kind of object, and can be manipulated as an object.

- The choice between op and vtable function boils down to a question of 
whether different PMCs need to be able to implement the behavior 
differently. For 'find_method' the behavior is different between Class 
and Object, alternate object models need to be able to implement it 
differently, and PIR subclasses need to be able to override it. So, it 
really needs to be a vtable function.

- AUTOLOAD is implemented by overriding 'can' and 'find_method'. For an 
object with AUTOLOAD, 'can' reports true for all method names it's 
willing to support, and 'find_method' creates (and optionally caches) 
the created method. It's true that an AUTOLOAD class can't return a hash 
of all potential methods for 'inspect_str'. But, it can return a 
pseudo-hash that's linked to the class, to create methods as they're 
requested (and optionally cache them in the class). This stems from a 
core design decision "Classes that interact with Parrot's base object 
model need to support introspection." That is, we require certain API 
feature support, but put no restrictions on how a particular 
implementation of the API supports those features.

Thanks to all for the valuable discussion,
Allison


More information about the parrot-dev mailing list