On 25.03.2014, at 21:07, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:

> OK, I see this works anyway because ByteString>>at:put: will handle the case and use becomeForward:
> 
> But should we rely on this expectation? It comes from a Smalltalk where become: were cheap.
> For example, WriteStream>>pastEndPut: does not preserve collection identity
> 

People rely on this :) 
I actually only got there because a Seaside test failed that made this expectation.

Speaking about expectations.

When I have an A, and I say

	WriteStream on: A

I actually expect the stream to be “on” A.
Become would be ok with me, because the new thing would
be A still, but the collection replacement that happened
up until now would not qualify any longer to be “on A”.

Regarding #pastEndPut:, yes this is debatable, but sending 
#pastEndPut: clearly shows that the caller is aware that
the put thing would end up beyond our beloved A. Which makes
this a mere exceptional behavior (not in general but in regard
to the “on A” expectation). It’s a “here be dragons” situation for 
me, so anything™ could happen.

Best
	-Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1625 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140325/2b0688ad/signature.pgp