Larry Wall wrote:
>'Course, I left out everything about prototype objects there...
>
>The name Foo also (in context) represents an uninitialized object of
>the class in question. Any object, initialized or not, can get at
>its type handlers by saying
>
> Foo.meta
> $foo.meta
>
>and, in fact, the Foo.^bar syntax is just short for Foo.meta.bar.
>
>
Perhaps saying it is like:
Foo.meta.get_attribute("bar")
Would be safer. Don't want to stomp on the meta-objects.
>[...]
>of the actual magic being defined elsewhere. It would be possible
>to access classes et al. only via the mechanisms supplied by the
>metaobject protocols, but that would be kind of like the bad old
>[...]
>
>
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. They are
actually quite a useful set for the concerns I raised earlier about
automatically inferring relational information from the metamodel (if
only I knew these terms back then... ;))
http://groups.google.com/groups?threadm=200303042358.56560.sam%40vilain.net
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.
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.
On different note, there should be nice, per-class ways to make type
constraints not simply code blocks - otherwise too much reverse
engineering will be required to do the final stage of compiling typesafe
code, where you close the classes and discard all the runtime type checks.
An easy example of this is generics. With "where", this is what you
write (ignore the syntax errors for now):
class "Array of Str" is Array where { $_.isa(Str) for @$_ }
But that sucks, because that information about the type of the container
is buried deep within the code reference, is slow, and we can't build
our methods with the right signatures. So, we write;
role Array[::T] { ... }
class "Array of Str" does Array[Str];
Great. Now that information is available to Array in a structured manner
and the signatures can be built correspondingly. But to represent the
core types like Mapping or Set, we also need, for instance, the "unique"
constraint to be represented as an object, not a code block:
For instance,
role Mapping[::T1, ::T2] does Coll[::T1, ::T2] where Unique(0);
The "where Unique(0)" is the important bit. What is "Unique", and who
uses it? In my prototypes, I've been considering it being the job of the
composing class or role to handle that, as a meta-object method call.
So, the above might call Coll.meta.Unique(0) (look, I'm stomping all
over the meta-object now) during the composition of the "Mapping" role,
and it uses this to affect the methods that it builds until you get
something that behaves not entirely quite unlike a Mapping.
However feel free to continue to handwave for now. Personally I'd like
to see this synoptic before the Perl 6.0 release, to avoid the mistakes
of other (*cough* C# *cough* Java 1.5 *cough*) languages that slipped on
getting the generics in their libraries, to their ultimate detriment.
Sam.
