Larry ,
At the risk of essentially signing my own committal papers for the
local looney bin, I have to say that this make sense to me. But I have
a few questions and requests for clarification :)
On Jul 11, 2005, at 3:07 PM, Larry Wall wrote:
On Mon, Jul 11, 2005 at 09:46:30AM -0400, Stevan Little wrote:
: Ingo,
:
: On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
: >Hi,
: >
: > class Foo {}
: > class Bar is Foo {}
: >
: > Bar.new.isa(Object); # true
: > Bar.new.isa(Class); # false
: > Bar.new.isa(Foo); # true
: > Bar.new.isa(Bar); # true
: > # These are clear, I think.
:
: Yes, these all make sense to me.
:
: >
: > Bar.isa(Object); # true
: > Bar.isa(Class); # true
: > Bar.isa(Foo); # ? (my guess: false)
: > Bar.isa(Bar); # ? (my guess: false)
:
: I am not sure about this. I think that .isa as a class method should
: behave much as it does for an instance method.
Right, or you can't easily decide whether Bar isa Foo in the abstract.
You need to able to reason about the relationships of user-defined
classes in the absence of instances.
: If we start supporting
: things like Bar.isa(Class) then we start exposing the soft underbelly
: of the meta-model to the outside world. Which IMO might not be a good
: idea.
Bar.isa(Class) probably false in any event, since I think Class
is probably a role rather than a class. But "Class" is almost
certainly not the name of the metaclass either.
No, the metaclass is called MetaClass of course :)
But if I want to be picky, then I should point out that:
MetaClass.isa(Class); # false
MetaClass.isa(Object); # true
Because MetaClass is really just a plain old class which just happens
to also take part in it's own definition.
Or at least,
it's not the name of *both* metaclasses (counting the Class role
as one of them). Basically every user-defined class has a Platonic
description (known as its "Class") and an Aristotelian description
(known as its "MetaClass").
So am I correct in my assumption that by "Platonic" you mean that the
"Class" of a user-defined class is not really meant to deal with the
"guts" of what makes up a class. That it is erring towards the pure and
clean more then towards the practical.
And by "Aristotelian" you mean much the opposite (sort of). That the
"MetaClass" of a user-defined class is where all the "guts" of the
class resides. It is a full description of the structure of the
user-defined class, and all it's ugly "practicallities".
So going away from philosophy 101 here, and back to CS, it could be
said that a "Class" has-a "MetaClass" (although not in the strict
user-level-OO sense of the word).
Am I correct in my assumptions? Because if so, then this paragraph...
So what is certainly true is that Bar.does(Class), where the Class role
describes the Platonic interface of items like Bar. That is to say,
Bar is the stand-in for all the members of its class when you don't
actually have a member. Its Platonic role is to know about Barness,
not about classness. We call call it the dispatcher class because
it knows how to dispatch things of type Bar whether you actually have
an instance of type Bar or not. That's why method calls on it can do
things like call constructors. But it doesn't know much about any of
the grubby Aristotelian workings of the metaclass. It just knows there
is one, and that it can delegate all the messy practicalities to it.
... makes sense to me.
I suspect the metaclass of "Class" actually has the name "class" or
"CLASS", and the metaclass of a Role is actually "role" or "ROLE".
Perhaps the "class" and "role" keywords are just specific examples
of the grammar being smart enough to treat declared metaclasses as
BEGIN analogues. But maybe it's smarter to keep the "class" and
"CLASS"
identifiers at arms length from each other. (If for no other reason,
to keep our sanity while discussing them.)
Sanity? bah! it's overratted, especially when discussing meta-models :)
So anyway, that gives us something like:
Bar.isa(Foo); # true
Bar.isa(Bar); # true
Bar.isa(Class) # false presuming Class is only a role
Bar.does(Class) # true
Bar.does(CLASS) # false
Bar.meta.isa(Foo); # false
Bar.meta.isa(Bar); # false
Bar.meta.does(Class) # false
Bar.meta.isa(CLASS) # false presuming CLASS is only a role
Bar.meta.does(CLASS) # true
You know, this class/role distinction might just be what saves our
collective bacon on the usual infinite regress of metaclasses, if a
metaclass turns out to be an object of anonymous class but named
role.
What difference does it matter if
$obj.meta.meta.meta.meta.meta.meta.meta.meta.meta is possible or not?
All the stuff I have read so far seems to say that at some point in all
object models there is a cycle. That cycle is basically where you have
something which is an instance of itself (Object is an instance of
Class, Class is a subclass of Object, Class is an instance of Class). I
mean is infinite regress really a bad thing?
The bootstrap might reside entirely in the code that constructs
the metaclass instance of anonymous class but filling the CLASS role
in its abstract interface.
I am ignoring the bootstrap idea for the time being in the prototype,
as it tended to muddle all my previous metamodel attempts, and I can
always refactor to it in the end. However, I found that the bootstrap
is either best placed at the point of the cycle (like in CLOS) or
spread throughout the basic classes (like Smalltalk (or at least
Squeak) seems to be).
Where that point in the Perl 6 model is, I have yet to find out, but I
am sure it will show itself soon enough.
I mentioned the idea of autogenerating a class Int from a role Int,
but maybe some roles don't allow themselves to be autogenerated into
classes, and maybe CLASS is one of them. And it sounds to me like
the absence of that feature is caused simply by ROLE's autogenerate
interface being left with an implementation of {...} and not overridden
in the anonymous metaclass representing the CLASS role.
So I guess the deep answer to the infinite recursion problem is that,
yes, it's metaclasses all the way down, but if you actually try to
pursue it, you'll at some point run into "method not yet implemented"
because nobody has cared about it that deeply yet.
I disagree with this. You hit the object-model cycle and it will never
stop.
So we basically
get the possibility of mapping to anyone's metamodel without actually
having to commit to the fanciest one.
I am not 100% sure of this either, however, I do think the Perl 6
object model is robust enough to be able to map to or mimic any other
object model out there. In fact Perl 5 is robust enough to do this too
:)
Stevan
I think I like that, even if
I don't understand it. Or maybe *because* I don't understand it.
Larry
