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.


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.
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?


   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.

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 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.


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? 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?

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.


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!

Reply via email to