On Tue, Jul 31, 2018 at 6:41 PM Damien Pollet <damien.pollet+pharo@gmail.com> wrote:

On Tue, 31 Jul 2018 at 18:28, Damien Pollet <damien.pollet+pharo@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)

��

Yes. And to me it's ok if Clap defines his own good usages of streams. Clap's usage of stream is not a typical file access.

��

For instance, it seems to make sense to provide stdout already wrapped with ZnNewLineWriterStream,

Also,��ZnNewLineWriterStream needs only to be used when interacting with the external word.

The rationale of keeping it separate is twofold:

- Zn* streams are meant to be reusable with other kind of streams��that are not files��(such as streams in memory) where the newline conventions do not need to be *always* enforced because the image has internally its own convention (crs).

- Zn* streams are meant to be reusable with other kind of streams that are not files (such as sockets) where maybe we want *also* to enforce line ending convention.

��

but that precludes users from buffering.

Yeap. This makes me remember I tried a buffered file stream on /dev/urandom and the buffering introduced some funny effects :)

��

- 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 <sven@stfx.eu> wrote:

> On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven@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.

--

������

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 Web: http://guillep.github.io Phone: +33 06 52 70 66 13