[self-interest] Re: Adding method slots dynamically

[Toby Ovod-Everett]

On Wed, Aug 17, 2005 at 12:47:39PM +0200, jbgarcia at uvigo.es wrote:
> 
> Hi, Jecel !
> 
> Thank you for your answer.
> 
> 
> > > What's the role of the mirror, here ? Is it related to preformance ?
> > 
> > It isn't a performance issue at all, but rather a matter of good object
> > oriented design. The paper I mentioned last month goes into details
> > about why mirrors are a good idea (http://bracha.org/mirrors.pdf) but
> > here is a short answer:
> 
> 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.
> 
> 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.

Placing all of the mirror slots into a generic "Object" object also introduces
the possibility of name collision should one desire to add additional
functionality to the mirror down the road.  Isolating the reflective behavior
into a mirror object has the benefit of creating a new namespace that is, in
effect, named "reflect ".

Having co-implemented Self-like behavior in Perl (see Class::Prototyped), it
was a big sigh of relief to move all of the mirror behavior into a mirror
object, for it meant I could add behavior to my heart's content without
worrying about the potential for namespace collisions/occlusions.

--Toby Ovod-Everett