Re: two questions...

[jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.)]

dougo@pure.com  (Doug Orleans) wrote:
> Subject: two questions: assignment to slots, and mixins with state
> 
> [ introduction ]
> 
> Suppose I have an assignable slot x:
> 
> _AddSlots: (| x <- 3 |)
> 
> I use x to retrieve the value of the slot, and x: to assign to it.
> Now what if I want to keep track of the number of times x has been
> assigned to?  I can add a new slot that gets incremented every time x:
> gets invoked:
> 
> [ implementations ]
> 
> it recurses infinitely.  I've tried a bunch of other ways to assign to
> x without using x:, but none of them work.  I can define a new slot to
> hold the actual data:
> 
> _AddSlots: (| _ theRealX <- 3.
>                 x = ( theRealX ).
>                 x: newx = ( numAssigns: (numAssigns + 1).
>                             theRealX: newx )
>             |)
> 
> but this seems kinda lame.  Am I missing some bit of syntax to assign
> to a slot, or is there some other easy way of doing this?

I think there is no good solution for this, as the assignment slot
is associated by name to its data slot. If you do something else
with the "x:" slot, then "x" is infered to be a constant slot.

You could use data parents, but this is not a very elegant way to
do it:

_AddSlots: ( | dataParent* <- ( | x <- 3 | ).
               x: newx = ( numAssigns: numAssigns + 1.
                           dataParent.x: newx ).
               numAssigns <- 0.
               copy = ( _Clone dataParent: dataParent _Clone )
           | )

Of course, I shouldn't be using _Clone directly like this, but
I didn't want to clutter the example with the necessary parent
slots.

I personally prefer your "theRealX" solution.

> My other question has to do with mixins.  Is there a typical way to
> implement a mixin that has state?  Say I want to make a mixin for an
> accumulator:
> 
> [ a few code variations ]
> 
> but this means that each object that wants to accumulate has to know
> that it needs to define an accumulator slot, as well as define the
> mixin parent slot.  There are two ways I've thought of to improve on
> this: define a clone method on mixins accumulates, and have it add the
> accumulator slot, followed by a resend; or define an
> accumulatesPrototype object that defined the accumulator slot, having
> each object that wants to accumulate have an additional data parent
> slot that points to a clone of the accumulatesPrototype.  The former
> solution would probably require that all the mixin parent slots have
> different priorities or something, which are all higher than the
> normal parent slots; this doesn't really seem workable.  The latter is
> similar to the filledPolygon example in figure 3 of the "Organizing
> Programs Without Classes" paper, but it involves having each instance
> be a number of objects, instead of just one, and this seems clumsy
> too.  Are there commonly used techniques to deal with this situation?
> I guess this problem doesn't apply just to mixins, but this problem
> came up when I was defining a mixin.

There was ( is? ) a discussion on this list about copy-on-write slots
that would do exactly what you want. This is present in several other
languages ( NewtonScript was mentioned, see the March 1994 Byte ) but
is a little at odds with the ideas behind Self.

BTW, parents no longer have priorities> Though their main practical
use ( breaking up large traits objects into catagories ) is now
done via annotations, dynamic inheritance and data parents are
a little trickier than before.

- Jecel