[Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference

> Hi
>
> Do we really want this?
> I do not understand why a string is a fileReference?
> String has far too many methods and we are even adding more and I do
> not understand why.
>
> Stef
>
>
> On Thu, Dec 14, 2017 at 12:01 PM,  <[hidden email]> wrote:
>> There is a new Pharo build available!
>>
>> The status of the build #381 was: SUCCESS.
>>
>> The Pull Request #605 was integrated: "20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference"
>> Pull request url: https://github.com/pharo-project/pharo/pull/605
>>
>> Issue Url: https://pharo.fogbugz.com/f/cases/20796
>> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/381/

> Hi Stef,
>
> On 16 December 2017 at 16:58, Stephane Ducasse <[hidden email]> wrote:
>> So I would like to understand (sincerly) what was the problem and what
>> is the gain?
>> I learned that we can ask a collection a readStream and writeStream already.
>> And now we can do anyCollection readStreamDo: and writeStreamDo:
>> Why not?
>
> Cyril proposed this, so may chime in with more information, but...
>
> Take a look at http://forum.world.st/Polymorphism-between-Strings-and-FileReference-tt5059220.html
>
> The advantages are:
>
> - provides polymorphism with FileReference
> - you don't need to know whether the stream needs to be closed or not
> as read/writeStreamDo: takes care of it for you.
>
>
>
>> On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse
>> <[hidden email]> wrote:
>>> Hi
>>>
>>> Do we really want this?
>>> I do not understand why a string is a fileReference?
>>> String has far too many methods and we are even adding more and I do
>>> not understand why.
>
> Can  you clarify what you're asking (about "why a string is a fileReference")?
>
> To be clear, SequencableCollection>>read/writeStreamDo: open a stream
> on the receiver (typically a string) and then pass it to the supplied
> block.  Nothing to do with a fileReference (apart from the
> polymorphism).
>
> Cheers,
> Alistair
>

>
>
> On Sun, Dec 17, 2017 at 7:00 PM, Stephane Ducasse <[hidden email]>
> wrote:
>>
>> Yes I check the code and since a collection already has readStream and
>> writeStream.
>> This is ok.
>>
>> I did not like the idea that we introduced this change just for the
>> sake of having strings polymorphic to fileReference.
>
>
> Yes, I don't see that it is bad in itself. Actually, I think the name of the
> issue is misleading :). I don't think about this issue as "make strings and
> files polymorphic" but "make streamable things polymorphic". If you know you
> receive a container with some contents (may be a string, a file, a socket, a
> zipfile...), you don't care about what the container is but if it is
> streamable. You want the contents!
>
> #readStreamDo: allows you to interface with such a streamable object without
> caring about its source. It is the source responsibility to close itself or
> not after the stream was used.

>> For the record readStreamDo: on collection does not close the stream.
>>
>> Stef
>>
>> On Sat, Dec 16, 2017 at 5:15 PM, Alistair Grant <[hidden email]>
>> wrote:
>> > Hi Stef,
>> >
>> > On 16 December 2017 at 16:58, Stephane Ducasse <[hidden email]>
>> > wrote:
>> >> So I would like to understand (sincerly) what was the problem and what
>> >> is the gain?
>> >> I learned that we can ask a collection a readStream and writeStream
>> >> already.
>> >> And now we can do anyCollection readStreamDo: and writeStreamDo:
>> >> Why not?
>> >
>> > Cyril proposed this, so may chime in with more information, but...
>> >
>> > Take a look at
>> > http://forum.world.st/Polymorphism-between-Strings-and-FileReference-tt5059220.html
>> >
>> > The advantages are:
>> >
>> > - provides polymorphism with FileReference
>> > - you don't need to know whether the stream needs to be closed or not
>> > as read/writeStreamDo: takes care of it for you.
>> >
>> >
>> >
>> >> On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse
>> >> <[hidden email]> wrote:
>> >>> Hi
>> >>>
>> >>> Do we really want this?
>> >>> I do not understand why a string is a fileReference?
>> >>> String has far too many methods and we are even adding more and I do
>> >>> not understand why.
>> >
>> > Can  you clarify what you're asking (about "why a string is a
>> > fileReference")?
>> >
>> > To be clear, SequencableCollection>>read/writeStreamDo: open a stream
>> > on the receiver (typically a string) and then pass it to the supplied
>> > block.  Nothing to do with a fileReference (apart from the
>> > polymorphism).
>> >
>> > Cheers,
>> > Alistair
>> >
>>
>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - http://www.cnrs.fr
>
>
> Web: http://guillep.github.io
>
> Phone: +33 06 52 70 66 13