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 <norb...@hartl.name>: > > > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <stepharo.s...@gmail.com > >: > > > >> 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. > > > > > 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.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 > >>> > >> > >> > >
