Guten Tag Herr Sandlaß,
On Aug 9, 2005, at 4:48 AM, TSa (Thomas Sandlaß) wrote:
HaloO,
Stevan Little wrote:
Here is a 10,000 ft view of the metamodel prototype I sketched out
the other day
(http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/docs/
10_000_ft_view.pod). It should shed a little light on this
discussion.
There you have
i(Foo) - instance of Foo
Foo - the user-level Foo class
class(Foo) - the instance of Perl6::Class named "Foo"
meta(Foo) - the instance of Perl6::MetaClass which describes Foo
The thing which is clear to everybody---even including stupid me---is
that
there is a 1:n relation between Foo and i(Foo). But then comes a three
part
referential chain Foo -> class(Foo) --> meta(Foo) that to me is
conceptually
*one* thing. The levels of indirection are implementation details,
right?
Yes, and no. Please see the second email I sent to Mark. It explains
the role I see for ::Class instances, and why they are not just
::MetaClass instances.
Also please keep in mind that I am an implementation monkey, and so
most anything I am documenting is likely to be the implementation and
not the theory. So assuming things are "implementation details" is
usually the right assumption :)
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
meta(MetaClass)
: ^
: :
V :
MetaClass -----+
^ |
: |
: |
meta(Object) |
^ |
: |
: |
Object <------+
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.
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.
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.
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.
Ahhh, the circularity of it all :)
Once you get used it it, it is really a beautiful thing.
- Stevan
--
$TSa.greeting := "HaloO"; # mind the echo!
