Lukas Renggli wrote:
>> Also, FWIW, if you like the ANSI version, it is easy to implement.
>> Here is a version using a dead forked dialect of Squeak; it should be
>> easy to dust it off should anyone want.  This version goes further
>> than discussed in this thread, and even makes floats and large integers
>> be immutable.  :)  The code is in islands.zip on the following page;
>> look inside the zip for immutLits1.5.cs and immutLits2.2.cs.
>>
>>   http://wiki.squeak.org/squeak/2074
> 
> In 3.8 and 3.9 there are 5 subclasses of String (Symbol, Byte and
> Wide) and many more for ArrayedCollection. Your change would introduce
> many read-only classes and lead to much duplicated code (ok, traits
> would be a big help here).

Just for the records, for strings there wouldn't be a need for more than 
a single new class. Here is why:

During the refactoring of the original m17n string hierarchy at one 
point I *very* seriously considered implementing Symbols differently, 
namely as a subclass of String with an iVar "string" that simply 
delegates the (few) actual requirements of the concrete subclasses to 
that variable. Pretty much the only reason not to do that was that the 
VM at places assumes that selectors are byte-indexable objects (like for 
printing debug stacks etc) and I figured that upsetting the internal 
String hierarchy was enough for one round without requiring additional 
VM changes (which turned out to be true, there was quite a bit of 
fallout in the aftermath of these changes and having VM dependencies 
would have made things unnecessarily harder).

However, it is *utterly* trivial to implement a subclass of String (call 
it "ImmutableString") that delegates the subclass responsibilities of 
String to an iVar and simply raises errors when trying to access them 
via #at:put: and friends. Then you simply implement 
String>>asImmutableString properly (^ImmutableString on: self) and off 
ya go!

Cheers,
   - Andreas