On 18 December 2017 at 11:37, Guillermo Polito <[email protected]> wrote: > > > On Sun, Dec 17, 2017 at 7:00 PM, Stephane Ducasse <[email protected]> > 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 <[email protected]> >> wrote: >> > Hi Stef, >> > >> > On 16 December 2017 at 16:58, Stephane Ducasse <[email protected]> >> > 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 >> >> <[email protected]> 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
