On Mon, Jul 11, 2005 at 05:35:41PM -0400, Stevan Little wrote:
: 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).
Yes, though I think of it more as delegation. Of course, delegation
can be construed of as pretending a reference type is a value type,
so it comes out to "has a ref to" plus syntactic sugar for redispatch.
: 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.
Yes, I think you've got it.
: >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 :)
Well, sane or not, we'll still have to figure out whether it's better
to call it "CLASS" or "MetaClass". :-)
: >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?
I don't mind looping it as long as we don't actually get caught in
infinite loops because of it. Or if we do, as long as we can blame
it on someone else. :-)
: >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 ain't a meta-model expert, so I'm just trying to look out for
the sanity of all the other meta-model-non-experts. Within those
constraints, I don't care how it comes out.
: >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.
Shrug. I don't plan to get close to there myself...
: > 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
: :)
I think the place where meta-model extensibility breaks down is
if you've nailed concepts to particular names that can't then be
bifurcated. So maybe we should tell people to avoid using names for
meta classes, and always try to name them by mentioning some class
they're the metaclass of. But maybe that's overkilling the topic.
On the other hand, I'm pretty sure I *don't* want to guarantee that
Foo.meta.class =:= Bar.meta.class
for all Foo and Bar, since I think that is probably false if Foo is a
class and Bar is a role. It might even be that
Foo.meta.class.meta =:= Bar.meta.class.meta
is usefully false.
But given our syntactic mutability, it's probably okay for now to nail the
"class" and "role" keywords to metaclasses whose names match m:i/class/
and m:i/role/ respectively, however they're actually spelled.
Larry
