On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <s...@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. > 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.s...@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 <emdon...@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 >> > >
