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). 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. The contract of a stream should be much, much simpler than it is today. 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 >
