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.
The next level where a 1:n relation exists is below meta(Foo) to pure
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.
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?
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.
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
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.
OK, it's slightly more complicated because classes can have class
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
Hmm, again: what distinguishes classes from objects and meta classes from
meta objects? 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?
there is multiple inheritance that adds edges into the tree which
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.
Ahhh, the circularity of it all :)
What is the benefit of the circularity?
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 :)
$TSa.greeting := "HaloO"; # mind the echo!