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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
