Hi all, Don't forget also that this are the low level bricks used in Pharo. Utterly required by the bootstrap and the minimal image, thus keeping dependencies small and controlled is a big +.
Magic and automatic stuff can be added on top. Nothing prevents to add a little layer on top as a separate library (I even encourage people to do so!) adding a builder, or a DSL to ease the construction of streams in the most performant way possible. Pharo has extension methods, and even this could be done with some extra objects managing the creation of the stream without being too complex. Guille On Tue, Mar 20, 2018 at 3:12 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > > 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 > > > > -- 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
