Jecel Mattos de Assumpcao Jr.
jecel at lsi.usp.br
Fri Apr 8 18:43:10 UTC 1994
dougo at 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
_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
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
> [ 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.
More information about the Self-interest