Very strange bug on Streams and probably compiler

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

Immutability should be an instance-level property and not special
class. Immutability is completely ortogonal to inheritance und
therefor should not abuse the inheritance mechanism. I know that a
change like this would require some deep changes to the object
representation in the VM. I just hope that someday somebody dares to
make the step from 3.x to 4.0 where something like that is maybe
possible ...

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli wrote:
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

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

Certainly that will work for String's in 3.7. In 3.8 there is also
ByteString and WideString. Futhermore you would probably also need
immutabilty for other instances like LargeInteger's, Float's, Array's
and maybe some other classes.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

"Lukas Renggli" <[hidden email]> writes:

Good point, there was just one String back then so it was simpler.

Still, there should be a reasonable way to engineer this at the image
level.  Smalltalk is a pretty cool language.  :) And adding immutable
strings and arrays, should be easier than adding a generic
immutability system.

A generic immutability system would be cool, though.  You could catch
some bugs with it.


-Lex

On Mar 7, 2007, at 23:45 , Lex Spoon wrote:

What Andreas was saying (IIUC) is that the abstract String class  
provides default implementations for all String functions that use a  
very small number of "kernel" methods that are declared subclass-
responsibility. That means all the rest of the code in the String  
subclasses is just an optimization, so adding a new subclass should  
be straight-forward.

This of course assumes that people actually honor that design and not  
bypass it by adding functionality to String subclasses directly.

- Bert -