On 5/23/06, Sam Vilain <[EMAIL PROTECTED]> wrote:
Right, but we should really ship with at least a set of Meta Object
Protocol Roles, that covers the core requirements that we will need for
expressing the core types in terms of themselves;
- classes and roles
- attributes and methods
- subsets (ie constraints/subtypes)
- generics (including, by induction, nested generics)
I *think*, at this point, that's all that are necessary.
I would maybe add a protocol for instance creation. We have recently
added that to Moose, and found it very useful in terms of abstracting
out the kind of instance storage used (ARRAY based storage currently
Just Works given the right Instance sub(meta)class).
I see the instance protocol as being an important component of cross
language runtime thing. If all instances conform to, or can be made to
conform to, an base instance protocol, making Perl 6 objects which
inherit from Python objects should be fairly easy.
People can instantiate the roles that cover all that to an actual
metaclass in whatever way they like (eg,
Moose::Meta::Class->isa(Class::MOP::Class)), but not having to detect
the type and then figure out how to talk to it for at least the core of
the object system would be good.
I think the roles can serve as the core interface nessecary to
function with the base object system. As long as my metaclass .does()
the correct role, it should be able to function in the object system.
Of course the old garbage-in garbage-out rule applies, we should give
you enough meta-rope to shoot your meta-self in your meta-foot.
People can diverge completely with completely incompatible metaclasses
that don't .do those roles, the only side effect of which being that
people who write code for the standard Perl 6 metamodel will be
incompatible, and maybe some ways of setting up the class won't work
without another layer of trickery. I *think* that's what you're getting
at. Of course, it shouldn't be prohibited just because it smells.
I am not sure I like this, incompatible metaclass issues are really
really tricky and hard to debug (aka - smells *really* bad). And the
system needed to support them really can bloat the metamodel internals
in a nasty way. There are several papers out there on the subject,
none of which IMO provide a satisfactory solution. The problem then
becomes compounded by introducing the Python and Ruby metamodels into
the fray. Having a single compatability level made out of roles is not
that much of a restriction really, and keeps much of the system
interals clean and orderly. It also makes it much easier for use to
add new metamodels from other languages by just by writing a layer to
map to the core metamodel roles.
- Stevan
