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

[David.Ungar@Eng.Sun.COM (David Ungar)]

Interesting questions!

We have been debating the data-slot-renaming issue for what seems like years!

Personally, I do not favor the "add the slot name to the assignment primitive"
solution, in fact, I have come to feel that assignment slots as such were a
mistake
in the first place! (I take the blame.)

I believe that containers are a basic notion that are at a comfortable level for
people to use, and that such comfortable levels are the right place to
ground out the
language. In other words, both the current scheme and the "add the slot
name to the assignment prim"
scheme are both too low-level, even though the latter makes certain
examples more elegant.

Instead, I like a scheme that, I recall, Lars has (also?) come up with:

everything is an object
objects have slots
code slots have a name and a method
data slots have a name,
 refer to an object (the contents) and also respond to name followed by a colon
 which redirects the reference.

In other words, there are no constant slots, and assignment and data slots
are folded into
one thing, a data-slot, which actually responds to a pair of messages.

Now you could allow the pair to be customized so that the accessor and
assigner did
not match, but I would rather just force you to rename and forward in those few
cases, in order to keep the simplest case (x and x:) be the simplest, as
well to preserve
the feature that when you see x you know the assignment is x:.
But I know that this last is not on as firm ground as the other. Still...


As far as the accumulating point is concerned, I guess I would have something
like a beAccumulating message that when sent to a point, cloned an
accumulatingPoint
filled in the state, and returned it.  Kind of pedestrian, I guess.



-- Dave