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.
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