To add to what I explained re: Class objects.
We have instance methods and class methods now in Perl 6, as well as
instance attributes and class attributes. The way I view Class objects
are as such:
A Class object is to class methods as an instance is to instance
Meaning, the Class object will be invocant of all the class methods. It
is of course possible to also then have the metaobject protocol act
upon that class object (meaning the methods defined in the meta-object
protocol would have the class object as the invocant), but in my mind
that could present namespace issues. For instance, the meta-object
protocol which is begun in Apoc/Syn 12 talks about a .name, .version
and .authority methods. I could see very easily where the meta-object
protocol could conflict with user defined class methods of the same
So by having the Class objects be the invocants for class methods, and
the MetaClass objects be the invocants for the methods defined by the
meta-object protocol, we are avoiding any namespace clashes.
Anyway, just wanted to add that :)
On Aug 8, 2005, at 5:49 PM, Stevan Little wrote:
On Aug 8, 2005, at 4:26 PM, Mark Reed wrote:
Coming in late here, but it seems odd to have an actual class called
"MetaClass". The meta-object protocols with which I am familiar have
concept of a metaclass (a class whose instances are themselves
the class Class is such a metaclass, but where does a class named
I discussed with Larry at the hackathon about the role that Class
played in the metamodel. We decided that is was but a thin veneer
between the meta-land and the user-land. I assume this is still the
case. Here is a 10,000 ft view of the metamodel prototype I sketched
out the other day
10_000_ft_view.pod). It should shed a little light on this discussion.
As for how this differs from the other MOPs out there. I took the
basic design of MetaClass, Class, Object from Smalltalk -80 actually,
but modified the relationships a little to be more has-a the is-a. Let
me expand/digress on this slightly ..
The basic Smalltalk-80 idea of every user-level Class having an
associated meta-level Class is still retained. However in Smalltalk,
Class is an instance of MetaClass, where in the metamodel Class has-a
instance of MetaClass. And as I said, Class is really nothing special,
it but a level of indirection between the instance and MetaClass
I also borrowed many ideas from CLOS (in particular from book "The Art
of the MetaObject Protocol"). CLOS is more like what you describe,
where standard-class is the metaobject to define classes. I see this
as mapping to the MetaClass, and our Class as being something akin to
the find-class generic function in CLOS.
If all metaclasses are instances of MetaClass, then MetaClass must
be an instance of itself - is this then the only cycle in the graph?
Yes, that is the cycle.
1) MetaClass is a subclass of Object
2) MetaClass is an instance of MetaClass
So the following code should be true (given a random instance $obj).
What does $obj.meta return - is it just a shortcut for
is something else going on here?
Well, I did not see $obj.class speced in A/S12 so I never did anything
with that. However the p6opaque instance structure I use in the
prototype metamodel has a pointer back to the class object (see the
10,000 ft view again). So it is simple to implement it if we want too.
But to answer your question, I was always under the impression that
$obj.meta returned the MetaClass instance associated with the class
that $obj is an instance of.
However, keep in mind, these are somewhat fuzzy areas in Syn/Apoc12,
and all details about $obj.meta only deal with "Introspection".
<best pirate voice>
Arghhh, these be uncharted waters 'mah Boy!
</best private voice>
If the former, then all of these should be true.
yup, this will always be true.
Again, no .class that I know of, however if there is, then these too
should be true.
I will agree with 1 and 3, but not with 2. I see Class and MetaClass
are seperate things, at least how I coded it. However this, should be
true (assuming we introduce a .class method):
However this is not a closed issue, so we can discuss it if you see a
real need for things to be this way.
However, Syn/Apoc 12 shows that the following is true if $foo is an
instance of the Foo class.
Hm. That doesn't make sense to me at all. Clearly I need to reread
Syn/Apoc. I'd expect $foo.isa(Foo) and that's it, although if
with composition is going on $foo.class == Foo would also be true.
Yup, doesn't make sense to me either :)