More on WriteStream>>on:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

More on WriteStream>>on:

Roel Wuyts
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

Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

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

Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Klaus D. Witzel
In reply to this post by Roel Wuyts
Hi Roel,

on Wed, 14 Feb 2007 18:47:05 +0100, you 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) ?
>
>
> Otherwise put, why should we not change the implementation of #on: in  
> Stream to do:
>
> on: aCollection

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



Reply | Threaded
Open this post in threaded view
|

RE: More on WriteStream>>on:

Alan L. Lovejoy
In reply to this post by Andreas.Raab
<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



Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Klaus D. Witzel
In reply to this post by Andreas.Raab
Hi Alan,

on Wed, 14 Feb 2007 22:06:16 +0100, you 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.
>
> Damien is right.  Either Streams should ensure their internal collections
> are unique to them,

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


Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Andreas.Raab
In reply to this post by Andreas.Raab
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

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


Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Roel Wuyts
In reply to this post by Klaus D. Witzel

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

> Hi Roel,
>
> on Wed, 14 Feb 2007 18:47:05 +0100, you 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) ?
>>
>>
>> Otherwise put, why should we not change the implementation of #on:  
>> in Stream to do:
>>
>> on: aCollection
>
> 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".

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.

>
> /Klaus
>
>> .... aCollection copy .....
>>
>>
>> --
>> Roel
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Roel Wuyts
In reply to this post by Andreas.Raab
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:

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


Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Roel Wuyts
In reply to this post by Andreas.Raab

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.

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


Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Nicolas Cellier-3
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
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Klaus D. Witzel
In reply to this post by Roel Wuyts
Hi Roel,

on Wed, 14 Feb 2007 23:19:04 +0100, you wrote:

> On 14 Feb 2007, at 14 February/19:14, Klaus D. Witzel wrote:
>
>> Hi Roel,
>>
>> on Wed, 14 Feb 2007 18:47:05 +0100, you 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) ?
>>>
>>>
>>> Otherwise put, why should we not change the implementation of #on: in  
>>> Stream to do:
>>>
>>> on: aCollection
>>
>> 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".
>
> Exactly. That is why the default behaviour could be to not destroy what  
> I pass to it...

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

>>
>> /Klaus
>>
>>> .... aCollection copy .....
>>>
>>>
>>> --
>>> Roel
>>>
>>>
>>
>>
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Roel Wuyts
>> Exactly. That is why the default behaviour could be to not destroy  
>> what I pass to it...
>
> 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?

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.

> Perhaps other people have some experience?
>
> /Klaus
>
>>>
>>> /Klaus
>>>
>>>> .... aCollection copy .....
>>>>
>>>>
>>>> --
>>>> Roel
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: More on WriteStream>>on:

Alan L. Lovejoy
In reply to this post by Klaus D. Witzel


<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



Reply | Threaded
Open this post in threaded view
|

Re: More on WriteStream>>on:

Klaus D. Witzel
In reply to this post by Klaus D. Witzel
Hi Alan,

on Thu, 15 Feb 2007 03:03:40 +0100, you wrote:

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

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