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 <[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 >
