On Feb 14, 2007, at 5:37 PM, Klaus D. Witzel wrote:
Stef,
why should strings be immutable, and why blame the compiler.
It's not about making string immutable but is wen you use it as a literal it should be immutable. This show use that literal that are not immutable make really bad tedious side effect. ( Same reflection for #(a b c ) )
Math
The same situation is, for example, with Associations. In order to prevent mutation, someone invented ReadOnlyVariableBinding.
Literals have nothing much to do with compiler optimization, see senders of #encodeLiteral:, just with determining the correct bytecode for pushing them onto the stack.
But of course the compiler could emit code for always copying string literals, if you can afford the performance penalty.
As Bert wrote: it's normal :)
[Okay okay other languages have immutable string, but this is Smalltalk.]
/Klaus
On Wed, 14 Feb 2007 16:56:56 +0100, stephane ducasse wrote:
Bert
It is normal.
No this is not. You get used to it and accept it.
You are modifying the 'a test ' literal into 'to test'. This modified string gets copied in the second test.
Lesson: never modify string literals.
It shows that the fact that the compiler optimizes the use of certain literals such as boolean and number is good for immutable objects but is wrong for mutable object such as strings.
Iin the semantics of Smalltalk nothing says that two strings with the same representation in the same methods are pointing to the same object. I did not check in which books but the difference between strings and symbols is really that two strings are pointing to two different objects, while symbols are referring to the same objects (and are immutable).
Stef