More on WriteStream>>on:

Could somebody who likes the fact that WriteStream modifies the  
collection passed with #on: give me an actual example where this  
behaviour is actually desirable/useful (I am not talking about  
ReadStream here) ?


Otherwise put, why should we not change the implementation of #on: in  
Stream to do:

on: aCollection

        .... aCollection copy .....


--
Roel

Roel Wuyts wrote:
> Could somebody who likes the fact that WriteStream modifies the
> collection passed with #on: give me an actual example where this
> behaviour is actually desirable/useful (I am not talking about
> ReadStream here) ?

Buffer streaming. It is very handy to be able to share the underlying
collection with a stream when you know what you are doing.

Cheers,
   - Andreas

Hi Roel,

on Wed, 14 Feb 2007 18:47:05 +0100, you wrote:

I would be strongly against such a copy; also a condition like  
(aCollection isString) would be way too much. The literal (which people  
seem to believe is a constant, it is *not*, it's a *literal* object) can  
only be decided by the *caller* to be constant. Besides of that:  
performance ...

Isn't #writeStream a very meaningful English wording? "caution, we are the  
*writers*, we *write* when you ask for #writeStream".

/Klaus

> .... aCollection copy .....
>
>
> --
> Roel
>
>

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

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

Hi Alan,

on Wed, 14 Feb 2007 22:06:16 +0100, you wrote:
Better not (assume anything about arguments passed in), see below.

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

Like for

  Smalltalk specialObjectsArray writeStream nextPutAll: {this. and. that}

> The second approach can be implemented
> using #become:.

Not always. See example above.

/Klaus

> --Alan
>
>

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.

Cheers,
   - Andreas

On 14 Feb 2007, at 14 February/19:14, Klaus D. Witzel wrote:

Exactly. That is why the default behaviour could be to not destroy  
what I pass to it...
But I was actually asking for real examples where the fact that the  
usage of one WriteStream has a side-effect on another WriteStream is  
useful.

Yes, for ReadStreams I have used because the data is shared. Do you  
use this for a WriteStream as well ?


On 14 Feb 2007, at 14 February/18:58, Andreas Raab wrote:

On 14 Feb 2007, at 14 February/22:57, Andreas Raab wrote:

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.

Roel Wuyts a écrit :
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

Hi Roel,

on Wed, 14 Feb 2007 23:19:04 +0100, you wrote:
Well, this "destroy" *is* subjective :) OTOH, typical example:

        out := WriteStream
                                on: (String new: 1000).

Of the 312 users of WriteStream in the current Squeak-dev .image, do you  
happen to know an example which does *not* pass a freshly  
instantiated+completely unused (alternately: an empty one like '')  
subinstance of ArrayedCollection?

> But I was actually asking for real examples where the fact that the  
> usage of one WriteStream has a side-effect on another WriteStream is  
> useful.

I don't load all the packages and investigate them only to answer what you  
can answer yourself, if that'd be what you mean.

Perhaps other people have some experience?

/Klaus

Well, in the current implementation they have to do this or you could  
be in trouble :-) :-)

But thanks, via a detour, for answering part of my question: I do not  
think that there are many usages of the fact that data is shared  
between two WriteStream instances. So then you could opt to make that  
the default behaviour. And have a version besides it for people (like  
Andreas) that know what they are doing. Or provide some more class  
methods to create the streams or something. Personally I do not mind  
that much: I am conditioned to not pass in String instances just like  
that.

Note, as I wrote in one of the other mails, that the system should at  
least become consistent (the problem with the collections growing and  
therefore being copied).

>> But I was actually asking for real examples where the fact that  
>> the usage of one WriteStream has a side-effect on another  
>> WriteStream is useful.
>
> I don't load all the packages and investigate them only to answer  
> what you can answer yourself, if that'd be what you mean.

:-) I did not expect (or anybody) to do this :-) Just whether offhand  
people could come up with one real example of two WriteStream's  
sharing a collection and depending on it changing. Note that this is  
actually quite hard to find in the code.

<Klaus D. Witzel>
Like for
  Smalltalk specialObjectsArray writeStream nextPutAll: {this. and. that}
> The second approach can be implemented using #become:.
Not always. See example above. effect
</Klaus D. Witzel>

Your example is problematic no matter how WriteStreams work. If the stream
makes its own copy of the Array, the code won't have the expected effect. On
the other hand, if it uses #become: on that particular Array...

I think your example demonstrates an issue with <Smalltalk
specialObjectsArray>, and not an issue with WriteStreams at all.

--Alan

Hi Alan,

on Thu, 15 Feb 2007 03:03:40 +0100, you wrote:
I don't think so. This is just an example of why to not assume anything  
about the arguments passed, especially not that arguments can be  
#become:'d without pain, headaches and the like.

FWIW my main point it to not compromize general use of WriteStreams, and  
not that I don't like it to be changed.

/Klaus

> --Alan
>
>
>
>