> On 20 Mar 2018, at 14:51, Andrew P. Black <apbl...@pdx.edu> wrote: > > I like the structure of streams wrapping streams from the point of view of > modularity of implementation and flexibility of reuse (as in applying > buffering and encoding to in-memory or network streams). > > But I don’t like exposing al the machinery to the user. For example, instead > of > > bufferedReadStream := ZnBufferedReadStream on: aReadStream. > bufferedWriteStream := ZnBufferedWriteStream on: aWriteStream. > > why not > > bufferedReadStream := ZnBuffer on: aReadStream. > bufferedWriteStream := ZnBuffer on: aWriteStream > > where the class that implements the buffering looks at the stream and decides > whether to do read or write buffering (or both, for a read-write stream).
Hmm, then I would prefer real object messages, like #buffered not class facades. > The meaning of #position: on an encoded Unicode stream is perfectly > well-defined. It’s just not the same as the meaning of position on the > underlying byteStream — one counts in codePoints, the other in bytes. Yes, agreed. > The old file streams got this wrong; I’m hoping that the new ones get it > right. However, the comment that > > "As a side note: using #size and #position[:] on variable encoded > streams > like UTF8 is *very* dangerous and should be avoided.” > > makes me worry that they do not. Please, either implement #size and > #position[:] correctly on the encoded stream, or don’t implement them at > all! Do *not* implement them incorrectly, and then tell me to avoid them > because they are dangerous! Well, I will repeat my opinion: #size #position #position: #reset have no place in streams. I have an experimental implementation of a ZnPositionableReadStream that adds 'excursion behaviour' as an add-on on top of more primitive streams that do not. It allows for code like stream savingPositionDo: [ "read ahead" ]. "continue reading as if noting happened" Here is the class comment. I am ZnPositionableReadStream. I am polymorphic with (the most used/important methods of) ReadStream and PositionableStream. I wrap another read stream and store the elements that I read in a sliding circular buffer so that I am able to go back to any position inside that buffer. Essentially, I implement #position and #position: to be used to back out of reading ahead. Note that the size of my buffer limits how far I can go backwards. A SubscriptOutOfBounds exception will be signalled when an attempt is made to go too far backwards. The index returned by #position should be considered abstract, without concrete meaning, but it is currently implemented as the count of elements read by #next on the wrapped stream. On a simple stream over an in memory collection, that will be equivalent to an integer index into that collection. But on network streams or streams that were already further along, this will no longer be the case. The most elementary example of my capabilities can be seen in my implementation of #peek. See also the unit tests #testPlainExcursion and #testSearch Of course, backing out of an excursion is only possible within the window of the buffer size. Implementation - stream <ReadStream> the read stream that I wrap and add positioning to - buffer <String|ByteArray> sliding, circular buffer - index <PositiveInteger> zero based index into buffer, where next will be stored - count <PositiveInteger> number of next operations done on wrapped stream - delta <PositiveInteger> number of positions that I was moved backwards The real core methods are #next, #atEnd, #position and #position: and are used to implement the rest. Part of Zinc HTTP Components
