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