mirrors (was: [self-interest] Adding method slots dynamically)

Jecel Assumpcao Jr jecel at merlintec.com
Wed Aug 17 15:43:59 UTC 2005


> I've browsed the article and I've also read your answer. Though there isn't
> anything wrong in Mirrors for me, I am not totally convinced about them.

I have adopted a different solution for Neo Smalltalk, so I can
certainly understand that no everybody likes this solution.
> If you don't have mirrors, then the functionalty related to reflection (i.e. the
> set of methods which actually add methods or attributes, etc.) will be in the
> "Object" or however the root of inheritance is named. I suppose this the way
> Smalltalk does it, this is the way Java implements it, and anyway it is the way
> I am implementing it in Zero ( http://trevinca.ei.uvigo.es/~jgarcia/TO/zero/ ).
> The only "bad thing" is that it makes the "Object" object to be quite "big", in
> terms of number of methods.

In Self you can have objects like

(| count <- 1. inc = (count: count + 1) |)

which does not inherit from some global "Object". In fact, it is a good
idea to use such objects whenever possible and only make them inherit
from "traits oddball" or "traits clonable" when they really need it to
do their job. This is the "principal of least authority" from the
security guys applied to object design.

> However, it will always have more functionality than the circle concept has. For
> example, you could create another circle sending the message "copy". In order
> to follow the path of pureness suggested by the concept of mirrors, perhaps the
> copy method should exist in another object of the library, the "factory" object
> or something.
> So, instead of doing:
> myCircle = Circle.copy()
> you could do:
> myCircle = Factory.copy( Circle )
> Or something like that.

Very true - you can consider cloning to be meta-level behavior and want
to put that into a separate object. A mirror would be a good place for
this. Of course, in the real world there are objects that can copy
themselves without external help such as biological cells.

Two advantages of the "copying is domain behavior" design used in Self
are that this is a very frequent operation so making it more lightweight
will improve performance and that having each object control this allows
the separation of "oddball" objects from "clonable" ones.
> A few kinds of mirrors ? Sorry, I don't understand. Why not a single Mirror
> object ?

Some objects only have named slots, others (vectors) have indexed
fields, others (methods and blocks) have code and others (small integers
and floats) have non standard encodings. So you probably want to
implement a method like 'slotNames' differently for the mirrors of each
different kind.

-- Jecel

More information about the Self-interest mailing list