Thanks Sven, we should take that list of selectors and make a document or Lint rules on them.
On Mon, Nov 13, 2017 at 9:08 PM, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > 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 > >> > > > > > > -- 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
