On Aug 9, 2005, at 12:36 PM, TSa wrote:
HaloO Stevan,
you wrote:
Guten Tag Herr Sandlaß,
you know that a formal German greeting in a collequial
environment can be interpreted as unfriendly? I don't
do that but just wanted to state the fact.
My apologies, no unfriendliness intended :)
The next level where a 1:n relation exists is below meta(Foo) to
pure meta.
Not entirely, class models are not as neat and tidy as type models,
you have many more cycles. To start with, meta(MetaClass) is an
instance of MetaClass (this is the traditional object model cycle),
it is also a subclass of Object, and then meta(Object) is also an
instance of MetaClass.
---> is subclass of
...> is instance of
I'm not a good meta modeler---actually I'm none at all.
They are icky beasts and can cause ulcers, I suggest avoiding them at
all costs :)
But I get as much as that you built a referential fabric
between five data structures. Some of them are used
for walking 'up the instanciation chains' and the other
for hangling along the 'subclassing links'. But what exactly
is the difference between these two? What are they used for?
Actually I think it is 4 data structures, if I understand your question
correctly. 1) the instance, 2) the magic 'Foo' class, 3) the class(Foo)
(is instance of Perl6::Class) and 4) meta(Foo) (an instance of
Perl6::MetaClass).
They are mostly used for walking 'up the instanciation chains' for
things like;
- to collect all relevant attributes
- method dispatch
- ordered destruction
- etc.
I do not hangle along the 'subclass links' because I actually don't
store subclass links. I considered adding them, but to be honest, I
have yet to encounter a real use for them short of introspection.
However since this is cyclical, you end up with the "Which came
first, the chicken of the egg?" issue. So in the implementation I
have created, the "X instance of X" part is accomplished through a
has-a relationship with the ::Class intsances, so that a ::Foo
instance has-a ::Class instance which has-a ::MetaClass instance.
Throw in some AUTOLOAD trickery and you have a prototype.
So, you basically create the gang of five above "from the outside"
and link them together. I've no problem with that.
Yes, basically, this is the bootstrapping code. It is the ugly
underbelly of the metamodel.
Am I missing something? Conceptually I see *one* MetaClass which
manages
its class instances which in turn manage their object instances.
No, there is no *one* MetaClass to manage them all. AFAIK this was
something they tried with Smalltalk 72 and found it was problematic,
so they went to the "every Class instance has a MetaClass instance"
and things worked out much better. However since I was not alive (and
certainly not programming) in '72 I cannot give you any more details
that that.
But Smalltalk is a typeless language that dispatches along the lines
of the (meta)class/(meta)object links. I propose to call this kind
of thing slot dispatch and reserve single and multi method dispatch for
the type based approach. Don't get me wrong, I consider them all as
equally usefull tools that belong into a state of the art programming
language. The only question is which gets the nicest syntax. And I
guess the meta model by its nature of beeing 'behind the illusion
of simplicity' has to take the burden of beeing somewhat uglier or
more verbose or some such.
Yes, the metamodel will surely have many ugly and verbose corners. This
is expected for bootstrapping a reflective metamodel of this kind.
As for your dispatch-ing point. I am not sure I understand what you are
saying, it seems almost as if you are arguing for a generic-function
approach like CLOS/Dylan rather than a methods-stored-in-class approach
like most mainstream OO. Is that correct, or am I reading in too far?
IMO, generic functions are really really really really nice things.
However, they are hard to understand for most programmers, so they are
not really viable (unless you hide them under a nice UI).
OK, it's slightly more complicated because classes can have class
instances
That does not make it any more complicated. If you think of ::Class
instances as being like regular instances, only just acting upon the
class level methods and attributes, you can see that things are
pretty consistent.
Hmm, again: what distinguishes classes from objects and meta classes
from
meta objects?
Nothing, everything is an Object (for the most part, that is). The
distinction between meta-level and user-level (or as they call it in
The Art of MOP, backstage and on-stage) is really an artificial barrier
which the interpreter sets up. The purpose of the meta-object protocol
is to document how much of the backstage is actually "visible" from
on-stage.
I mean other then beeing different nodes in a referential
fabric? BTW, is there a good name for it? I guess Matrix is also
over-used.
My view is that Perl6 should have
a name tree,
a type lattice and
a meta graph/model/fabric?
Sure that sound sane. However I am just the meta-model guy, the rest of
that list is not my expertise.
and
there is multiple inheritance that adds edges into the tree which
transform
it into a DAG.
Nothing in an object model is ever a DAG, there are always cycles.
And MI does not complicate things either, a MetaClass just holds a
list of superclasses, thats it, nothing more.
And I see also classless objects.
Yes, but those are not going to be handled in the meta-model, because
the meta-model is all about classes. You can however, build a
classless system on top of the metamodel, using classes of course.
Could it be the case that choosing the same terms 'class' and 'object'
on the meta level as on the user level is a *bad* idea? At least it
will be a source of confusion.
What else shall we call them? They really are classes and objects. I do
understand your confusion though, it took me a few weeks to get over
that in my head.
Ahhh, the circularity of it all :)
What is the benefit of the circularity?
It is the foundation of a reflective object model (reflective being the
key word here). Why? I have no real idea, that is just how it is done
everywhere I have seen, and I tend to defer to those who are far
smarter than I will ever be on things like this.
If you do not have the cycle though, you end up having to implement
everything on the meta-side in your runtime, which is partially how the
current JS version of the metamodel is implemented. The only thing in
that model which is defined in the user-level is Perl6::Object. In the
p5 version however, both Perl6::Object and Perl6::MetaClass are
actually defined in user-level code. Sure they use a lot of meta-level
hooks, but it is really user level code. And since this is user-level
code, it means it is user-level manipulatable :)
Once you get used it it, it is really a beautiful thing.
Infinite recursion is a great mental tool, indeed.
But somewhat difficult to implement without either
infinite processing time or infinite memory :)
This is where the bootstrapping comes in. When properly bootstrapped,
the model is stable and will not digress into infinite loops. Sure
there is some ugliness to account for the bootstrapping as well as some
hacks to take care of some meta-circular-stability issues, but all in
all, the model holds.
Stevan
