Hi Damien,
on Wed, 14 Feb 2007 17:58:02 +0100, you wrote:
On Feb 14, 2007, at 5:48 PM, Klaus D. Witzel wrote:
Hi Damien, on Wed, 14 Feb 2007 17:19:13 +0100, you wrote:
On Feb 14, 2007, at 4:36 PM, Bert Freudenberg wrote:
It is normal.
This is normal for you because you know how the compiler works. But do you think the compiler works normally? Is it normal that a compiler considers two equal strings as identical? I would agree with symbols because symbols are immutable. I think this is a first bug, a bug in the compiler.
In my opinion, there is another bug. When the collection of a stream becomes full, its is replaced by another bigger collection. So, first, the stream uses the collection you passed to the constructor, then, at a given time, this collection is replaced by a new one. I don't think it's a normal behavior.
Whatever the stream does with the collection, it is encapsulated. Imagine the stream always uses a highly optimized species for its internal job (or a file on your harddisk!). You should not depend any code on the internals of (in this case) stream.
I really don't want to depend on the implementation. And in my opinion, this is not encapsulated because this is MY String, not a String created internally.
Not really. If you pass a boxed object (other than a SmallInteger) the recipient can #become: it to anything he/she likes. This is reality.
What I see is that the String I give to the new Stream is modified. Then at a moment, the String does not reflect the stream anymore. This doesn't sound coherent to me.
It is not coherent because you passed an explicitly written *constant* which, in other languages, is believed to be immutable.
And if you all agree to the current behavior, then a documentation should be written: "Don't use the collection after having created a stream on it !"
Easier: don't pass constant collections to the streamers :)
Another example, not to blame on any streamer: | tmp | tmp := 'lowercase'. tmp translateToUppercase == tmp
/Klaus