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. > > 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
