> Yes, Zn streams focus on classic binary(byte) / character streams.
>
> Streaming over arbitrary data is very cool and well covered by the old ones.
>
> While I really like traditional streams I can not agree here. Sometimes it reminds me poor java collections which force writing loops all the time.
> For example the most common task in my experience was writing contents of read stream into write stream. And the only possibility now is loop.
> From this point of view XStreams really pushes streams to the level of smalltalk collections.

Yes, I agree, Xtreams is much better (but steep learning curve).

I just wanted to point out that my contributions in Zn streams focus and better/simpler byte/character IO.

Improvement on the classic streams are, of course, welcome.

> > About contribution: it is in external repository of Sven. Can we contribute with normal process, create pull request into Pharo repo?
> >
> > 2017-11-14 9:36 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>:
> > To a package next to block?
> >
> > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
> > What about contributing to zinc streams? Imaging that I will create block based streams, collecting:/selecting streams like in XSteam. Where I should put them?
> >
> >
> > 2017-11-13 23:51 GMT+01:00 Norbert Hartl <norbert@hartl.name>:
> >
> >
> > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
> > >
> > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
> > >> The idea is to have much simpler streams which can be composed to get more sophisticated behaviour.
> > >>
> > >> The most primitive streams should be binary read or write streams, like a raw file or network connection.
> > >>
> > >> To add a character encoding/decoding you wrap them in a ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, cleaner ZnCharacterEncoders).
> > >
> > > Yes really nice :)
> > >
> > > And Guille started to use them and we are slowly rewriting all the
> > > stream internal users to use Zn and after we will be free.
> > >
> > >
> > No, you will depend on zinc classes. How is that supposed to work in bootstrap?
> >
> > Norbert
> > >> If you want buffering, you wrap a ZnBufferedReadStream or ZnBufferedWriteStream around them.
> > >>
> > >> And there are some other examples in the system too.
> > >>
> > >> Have a look at BinaryFileStream and ZdcSocketStream.
> > >>
> > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must die, because they try to be everything at once and are impossible to change.
> > >
> > >
> > > YES YES YES and celebrate. I could never understand anything. My brain
> > > is too limited for these kind of games :)
> > >
> > >
> > >
> > >> The contract of a stream should be much, much simpler than it is today.
> > >
> > > Fully agree.
> > >
> > >>
> > >> For writing that means
> > >>
> > >> #nextPut:
> > >> #nextPutAll:
> > >> #next:putAll:
> > >> #next:putAll:startingAt:
> > >>
> > >> the 3 last ones can be written in terms of of the first one, but the last one is key because it can be the most efficient.
> > >> And maybe also
> > >>
> > >> #flush
> > >> #close
> > >>
> > >> Some helpers for character writing are
> > >>
> > >> #space
> > >> #tab
> > >> #cr
> > >> #crlf
> > >> #lf
> > >>
> > >> Maybe #newline
> > >
> > > :)
> > >
> > >
> > >>
> > >> #<< is a handy method too.
> > >>
> > >> For reading that means
> > >>
> > >> #atEnd
> > >> #next
> > >> #next:
> > >> #next:into:
> > >> #next:into:startingAt:
> > >> #nextInto:
> > >> #peek
> > >> #skip:
> > >> #upToEnd
> > >> #upTo:
> > >> #readInto:startingAt:count:
> > >>
> > >> Again, they can all be written in terms of #next, but #readInto:startingAt:count: is the core, efficient one.
> > >> Note that #peek allows a one character lookahead, which should be sufficient for almost all parsing needs.
> > >>
> > >> #close is also a necessary operation, #peekFor: a handy one, #nextLine is popular too.
> > >>
> > >> There is a discussion about positioning (#position , #position: and related) but these cannot be supported _in general_ by the kind of streams described above.
> > >>
> > >> If you absolutely need these, read #upToEnd and use a regular ReadStream (over a fixed collection).
> > >>
> > >> The collection based classic Streams should always remain in the system, they are too handy. But have you seen for example, #nextInt32 on PositionableStream ? Good luck with that when the the underlying collection is anything other than bytes.
> > >>
> > >> All this being said, there is no one, single correct answer.
> > >>
> > >> But if we all try to simplify what we expect of streams (use a more limited API), we'll be more nimble to make implementation changes later on.
> > >>
> > >> Sven
> > >>
> > >>> On 13 Nov 2017, at 19:58, Stephane Ducasse <stepharo.self@gmail.com> wrote:
> > >>>
> > >>> Hi Evan
> > >>>
> > >>> I think that we will use the ZnStreams.
> > >>> If we use Xtreams we will transform their API because some messages
> > >>> are not really good.
> > >>> Stef
> > >>>
> > >>>> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu@gmail.com> wrote:
> > >>>> I've heard mention once or twice on this list and in some release notes of
> > >>>> what sounded like possible coming changes to the stream API. Could anyone
> > >>>> point me to any concrete details about that? I haven't been able to dig
> > >>>> anything up myself by searching. I'm about to write something that I'd like
> > >>>> to be polymorphic with the stream API, but if that's about to change, I'd
> > >>>> like to plan ahead.
> > >>>>
> > >>>> Thanks,
> > >>>> Evan
> > >>>
> > >>
> > >>
> >
> >
> >
> >
> >
> > --
> >
> > 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
> >
>
>
>