We used to call such "changable values" especially when they were 
number-like: "gauges" -- and this is another reasonable 
interpretation for this -- which especially works in Smalltalk-80.

Cheers,

Alan

------

At 10:33 PM +0200 6/17/02, Andreas Raab wrote:
>Lex,
>
>>  You haven't tried to teach people to program, have you?
>
>I have. It's a while back and was mostly Smalltalk, but yes, I have.
>
>>  I have the biggest success in teaching people by teaching them
>>  Common Lisp, because there was little discussion at all on syntax.
>>  I've never tried Scheme, but I imagine it would be simpler.  The
>>  times I've tutored or taught people in Pascal, C, or Ada, the
>>  syntax has really gotten in the way. Smalltalk is hard for a
>>  different reason: you have to grok a bunch of the library
>>  before you can do anything.
>
>I agree - but the other languages are not hard simply because of += and
>friends. While I agree that "too much syntax" is hard to grasp, I would
>argue that "too little syntax" makes the experience less comfortable in
>the mid to long term. As always there is a fine line between "too much"
>and "too little", but for me, Smalltalk is clearly on the "too little"
>side. If += is on the other one stands to reason but I don't believe so.
>
>>  The worst cases I've seen are C++ and Java: you have the same
>>  difficulties from Smalltalk, plus you have a lot of
>>  syntax to learn.
>
>Agreed on all points.
>
>>  Aside from that, there is a possible cost even an expert programmer.
>>  Time spent learning the extra forms could have been spent becoming a
>>  better programmer in general with the existing forms.
>
>If the extra forms make it possible to write more readable, easier to
>maintain code I would argue that this is time well spent.
>
>>  There is an interesting parallel to functional languages, by the way.
>>  In functional languages, := is often a function, and the
>left-hand-side
>>  is a value holder.  That is, when you see  ":=" in a functional
>>  languages it is really  more like "value:" in Smalltalk.  (And ":=" in
>>  Smalltalk doesn't map over at all.)  The difference is whether you are
>>  talking about the variable (:=), or about the value the variable holds
>>  (value:).
>>
>>  To return to the point, the new += seems more like := than
>>  like #value:.
>
>Whoops? What makes you think that?! It's exactly the opposite - the
>entire intent is to ask the receiver to increase itself, e.g.,
>accurately represented it should be "foo addValue: bar". And the only
>reason the assignment form is required because some of the "more stupid"
>but unfortunately fundamental literals can't do it any other way.
>
>>  The new += affects the variable, not (typically) the value.
>
>Wrong. Exactly wrong. It *always* affects the value and only the value
>if propertly implemented. Again, the only reason for putting it in
>assignment form is because you cannot affect the value of a SmallInteger
>nor should it affect any of the other literals (like LargeInts and
>Floats). If you will reread my other posts you will notice that I always
>pointed out "polymorphic receivers" to which SmallIntegers and other
>literals belong. There is no single implementor of += besides these
>literals that do (or should) implement += in any other fashion than you
>are describing.
>
>>  In fact, there are existing implementations of += that
>>  are more like #value: -- just check out implementors-of +=
>>  to see 4 interesting implementations.
>
>Well, yeah, look at the initials of those methods ;-)
>
>>  Maybe we should leave += acting like #value:, and use a
>>  different syntax for the version that acts like :=.
>
>See above. In order to make += polymorphic (how often do I have to
>repeat this in this thread - this must the third or fourth time) it is
>required that += is an assignment form.
>
>Cheers,
>   - Andreas


--