Guillermo Polito wrote > On Tue, Jul 31, 2018 at 6:29 PM Damien Pollet <
> damien.pollet+pharo@ > > > wrote: > >> Hi Sven… a couple questions: >> >> - is there a preferred order of composition between the encoding and >> buffering streams ? If yes, it the same for read and write stream, or >> reversed ? >> E.g. if Stdio binaryStdin was implemented, Stdio stdin should be decoded, >> but buffering it as well would be a problem for interactive applications. >> > > Well, I'd say that we could check if performance-wise there is a > difference... I don't think there will be much of a difference, but, who > knows ^^. It can be a world of difference, depending on what operations are expensive on the terminal stream. For example, with a buffer size N, file <-> buffer <-> utf8 encoding does 1 N-byte write/read whenever buffer fills/need filling, file <-> utf8 encoding <-> buffer does N 1-4 byte writes/reads whenever buffer fills/need filling. TLDR; Always put the buffering between where small reads/writes occur (encoding, code doing looped #nextPut:'s), and where reads/writes are expensive (files, sockets, etc). Guillermo Polito wrote >> >> - what's your opinion on convenience composition messages, e.g. >> aBinaryStream buffered decoded: 'utf-8' ? >> > > Check what we did in FileReference & co. > Opening a File reference returns by default a utf8 buffered stream (in > that > order). And we have convenience methods to specify other encodings and to > get directly the binary stream (which will be buffered). > > The idea is that FileSystem (among others like managing memory file > systems) provides a high level API with convenience methods to avoid > putting the burden of the composition in the user. > The File package stays small and flexible providing direct access to the > physical file system. > > Following this same idea, to me Clap should define several convenient ways > to access standard input/output. > Like that, other Stdio users can define their own too. > > Also, maybe Clap can provide the same API as FileSystem > (#writeStreamEncoded:do:, #readStreamEncoded:do: & co) just for coherence? The problem with using buffered write stream composition in a non-scoped manner, is you have to remember to explicitly #close the streams in order for buffers to flush correctly. That is, unless one could have a #finalize on buffered streams; and ensure it runs before finalizer on the wrapped stream (which would cause the terminal to close, and subsequent #flush to fail), I'm not sure if that's possible/how it already works... Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
