Roel Wuyts a écrit :
> 
> On 14 Feb 2007, at 14 February/22:57, Andreas Raab wrote:
> 
>> Alan Lovejoy wrote:
>>> <Andreas>
>>> Buffer streaming. It is very handy to be able to share the underlying
>>> collection with a stream when you know what you are doing.
>>> <Andreas>
>>> Yes.  It would be even better to be able to do that wihout having to 
>>> know so
>>> much about what some other object might or might not do.
>>
>> I'm not advocating this as a general solution but I understood the 
>> question to be about whether anyone has ever used that and whether 
>> therefore such a change has the potential to break something severely. 
>> And indeed, if you know what you are doing, this can be very handy and 
>> very speedy.
> 
> It was indeed my question: get some real examples.
> 
> In fact, I need that you need both options. One which you know is safe, 
> and one that is shared and where you need to know what you are doing.
> 
> BUT
> 
> In the current implementation you actually have an implicit mixture of 
> both. You start out with a shared collection. But when it becomes too 
> big, it grows (so it is copied) and then they are suddenly decoupled. 
> That is not really as it should be.
> 

In VW, when it grows, it become:, so it is not decoupled.
In VW, #grow is a service of Collection, not something coded in 
WriteStream>>#pastEndPut:

This is also related to the problems experimented by Damien with
	WriteStream on: OrderedCollection new...

With a become:, it would also be safer to use WriteStream on a buffer as 
suggested by Andreas without potential writelimit bug.

Nicolas

>>
>> Cheers,
>>   - Andreas
>>
>>> Damien is right.  Either Streams should ensure their internal 
>>> collections
>>> are unique to them, or they should assume that other objects have 
>>> references
>>> to those collections, and might be expecting the stream to always be
>>> referencing the same collection.  The second approach can be implemented
>>> using #become:.
>>> --Alan
>>
>>
> 
> 
>