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