"Andreas Raab" Andreas.Raab@gmx.de wrote: > 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.
Urk. So if I do x := 3. x += 1. it should affect the value (3) and ONLY the value, so after this x is still 3, and 3 is still unchanged because you can't change numbers?
Now I am really confused. (And I've used update assignment in a lot of programming languages, including an APL dialect, since about 1974, and I've implemented it a couple of times.)
Can we have a clarification, please? In the form <lhs> += <rhs> What are the allowed forms for <lhs> and <rhs>? What are the allowed values for <lhs> and <rhs>? Can the effect be explained by a source to source transformation? If so, what is that transformation? Does the same transformation work for <lhs> things that have an immutable object as value and for <lhs> things that have a mutable object as value? Does the <lhs> (or its value, or whatever) have to support #+=? If not, will a suitable #+= be automatically defined?
> 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 ;-) I'm rather unhappy about a += that isn't *automatically related* to +. (Even more so about B2Color4Array that does have #+= but does not have #+.)
The existing uses have the property that x += y is an ordinary message send that alters the object that is the value of x, but does not alter x itself.
I really hate inconsistency in a language. It always ends up tricking me into making mistakes. I can like with a few ad hoc += methods scattered around the system that act like other message sends. But special syntax that sometimes does that and sometimes does something different will have me screaming for a Preference to turn it off.
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. It is already polymorphic.
Richard,
Urk. So if I do x := 3. x += 1. it should affect the value (3) and ONLY the value, so after this x is still 3, and 3 is still unchanged because you can't change numbers?
Right ;-) Notice that I wrote "if properly implemented" and unfortunately for some of the examples (like the above) it just cannot be properly implemented. E.g., if you take something like a "FloatArray with: 3" in your example it would work just the way described.
In the form <lhs> += <rhs> What are the allowed forms for <lhs> and <rhs>?
See original message: <lhs> - a variable name (for implementors that cannot properly implement it) <rhs> - any expression
Can the effect be explained by a source to source transformation?
See original message:
lhs := lhs perform: #+= with: rhs.
Does the <lhs> (or its value, or whatever) have to support #+=?
Yes. See the original message and look at the changes.
I'm rather unhappy about a += that isn't *automatically related* to +. (Even more so about B2Color4Array that does have #+= but does not have #+.)
It's inherited from FloatArray. Look at FloatArray>>+
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org