On Tue, 31 Jul 2018 at 18:28, Damien Pollet <damien.pollet+ph...@gmail.com> wrote:
> Hi Sven… a couple questions: > For context, I'm considering options in Clap, for providing accessors to Stdio that: - are convenient in most cases - discourage users from explicitly referencing the Stdio global (so that one can inject other streams instead if needed) For instance, it seems to make sense to provide stdout already wrapped with ZnNewLineWriterStream, but that precludes users from buffering. - 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. > > - what's your opinion on convenience composition messages, e.g. > aBinaryStream buffered decoded: 'utf-8' ? > > > > On Tue, 24 Jul 2018 at 10:13, Sven Van Caekenberghe <s...@stfx.eu> wrote: > >> >> >> > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <s...@stfx.eu> wrote: >> > >> > Stdio stdout and friends just return a binary stream, hence they need >> wrapping for encoding. >> > >> > Maybe >> > >> > Stdio stdoutAsText >> > >> > might be an idea, but this is so uncommon that I am not sure this is a >> good idea. >> >> Given all remarks and comments (thanks BTW), I now think that >> >> - textual stdio streams are the more common case >> - binary stdio streams are the primitive ones that are seldom used >> - another encoding than UTF-8 seems uncommon >> - these are streams that exist and need no real opening/closing >> >> So, >> >> Stdio stdout >> >> should return return a character write stream with UTF-8 encoding while >> >> Stdio binaryStdout >> >> should be the lower level binary one. >> This would be more in line with the other streams. >> A non-UTF-8 encoding can be used as per Pavel's example. >> >
