To a package next to block? On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <dionisi...@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 <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 >> >>> >> >> >> >> >> >> > -- 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
