[Pharo 7.0-dev] Build #381: 20796-String-should-understand-readStreamDowriteStreamDo-to-be-polymorph-with-FileReference
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%20...
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, <ci-pharo-ci-jenkins2@inria.fr> 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%20...
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? On Sat, Dec 16, 2017 at 4:42 PM, Stephane Ducasse <stepharo.self@gmail.com> 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.
Stef
On Thu, Dec 14, 2017 at 12:01 PM, <ci-pharo-ci-jenkins2@inria.fr> 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%20...
Hi Stef, On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self@gmail.com> 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-tt50592... 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 <stepharo.self@gmail.com> 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
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. For the record readStreamDo: on collection does not close the stream. Stef On Sat, Dec 16, 2017 at 5:15 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self@gmail.com> 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-tt50592...
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 <stepharo.self@gmail.com> 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 <stepharo.self@gmail.com> 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 <akgrant0710@gmail.com> wrote:
Hi Stef,
On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self@gmail.com> 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 <stepharo.self@gmail.com> 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
On 18 December 2017 at 11:37, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Sun, Dec 17, 2017 at 7:00 PM, Stephane Ducasse <stepharo.self@gmail.com> 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.
+1 Cheers, Alistair
For the record readStreamDo: on collection does not close the stream.
Stef
On Sat, Dec 16, 2017 at 5:15 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On 16 December 2017 at 16:58, Stephane Ducasse <stepharo.self@gmail.com> 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-tt50592...
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 <stepharo.self@gmail.com> 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
Phone: +33 06 52 70 66 13
participants (4)
-
Alistair Grant -
ci-pharo-ci-jenkins2＠inria.fr -
Guillermo Polito -
Stephane Ducasse