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