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 methods.

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 name.

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 :)

- Stevan

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 the concept of a metaclass (a class whose instances are themselves classes), and the class Class is such a metaclass, but where does a class named MetaClass
fit in?

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 instance.

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 $obj.class.class, or
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 the Syn/Apoc. I'd expect $foo.isa(Foo) and that's it, although if nothing fancy
with composition is going on $foo.class == Foo would also be true.

Yup, doesn't make sense to me either :)

- Stevan

Reply via email to