Re: two questions: assignment to slots, and mixins with state

[Randall.Smith@Eng.Sun.COM (Randy Smith)]

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

You have tripped upon what I think is a small, sore wart on the current
semantics of assignment.  We have talked about redoing assignment,
though it's not in our current plans.  One proposal is to make the
assignment primitive method (sometimes written as "<-") take an argument
specifying which slot it assigns to.  You might write this new
assignment primitive method as "<-[slotName]"

This would make it somewhat less awkward to trap assignment messages, or
to trap read messages.

So what you might write today as

        (| x <- 7 |)

essentially the same as

        (| 
           x      = 7.
           x: arg = <-.
        |)

would become

        (|
           x       = 7.
           x: arg  = <-['x'].
         |)


Then a trap to notify assignments would be

         (|
           trueX: arg = <-['x']
           x          =  7.
           x: arg     = ('Assigned x !' printLine. trueX: arg).
         |)

A trap to notify reads would be 

         (|
           x        = ('Read x !' printLine. trueX ).
           x: arg   = <-['trueX'].
           trueX    = 7.
         |)


In either case, you only need one extra slot ("trueX" or "trueX:"), not two.

Another up side to the proposal is that the story of what <-[x] means
is tidy: 

    x: arg  = <-['x'] 

is like
 
    x: arg  = ( (reflect: self) at: 'x' Put: (reflect: arg) IfFail: [error]).

The story for what <- means today is more awkward (there is no state in
<- so how does it know it is assigning to the 'x' slot?).

There are two downsides to this proposal (that I have heard so far).  

1] Today when you see an assignment slot in an object (| x <- 7 |), you
know that there are two slots, and that x: is not trapped: it is
guaranteed to contain "<-".  This simplifies the browsing task facing
the programmer.

2] What is the scope of the x in <-['x'] ? Can it only assign to the x
slot in this object? Or can it assign to a slot in some other parent or
maybe any object in principle? Some say the former is a reasonable
restriction, matches the reflective semantics given above, and
implementing the latter version would be very difficult.  Others argue
that the "within an object" restriction (though that is a restriction we
have today ) would start to feel unreasonable in this situation. After
all, we'd have pried apart the assignment and access slots, why not go
all the way?

Interesting that you stumbled over this so quickly!

	--Randy