Yes there was no mention of BOMs, but there *was* mention of
#position, and the presence or absence of byte order marks
makes a difference.

As for mailing list discussions over a year, that is not the
kind of single coherent source I was hoping for.

As someone *using* the system classes, I don't give a damn
how big they are.�� What I care about is the complexity of
*my* code, and it looks as though the new interface will
make my code bigger, more error-prone, and less portable.
As for the "big hairy classes" sneer, the file stream
classes put together in my system are about the same size
as the Dictionary class proper.

I don't "want to make users set environment variables".
What I was suggesting was that if a user does go to the
trouble of setting relevant environment variables, the
system should have the decency to pay attention to them.

handling /dev/std... is pretty trivial in UNIX; in Windows
nothing about stdin is easy (XP, Vista, 7, 8, and 10 differ
amongst themselves in several annoying ways).

I can make no sense of the comment that interpreting #'text'
as #utf8 (always, as a design choice) or as whatever the
user chose for $LC_CTYPE (always, as a design choice) is
"not very Smalltalk like".�� Both design choices are fully
consistent with the standard -- to the limited extent that
UTF8 processing *can* be consistent with the standard.


On 24 July 2018 at 05:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:


> On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz@gmail.com> wrote:
>
> Oh, I think a clarification is needed when talking about UTF-8.

Why ?

> To the best of my knowledge you don't need a Byte-Order-Mark at
> the beginning of a UTF-8 stream because there is no byte order
> issue to result,

Nothing was said about BOMs.

> but apparently many Windows programs like to add one.��

Apparently yes.

> Does/will Pharo add one when writing a UTF-8 file?

No

> Does/will it skip one when reading a UTF-8 file?

Yes

> I find the new approach produces unattractive code.�� I can do
> all of the examples simply in a system that
> (a) implements the ANSI Smalltalk FileStream class methods

Given a FileReference object of some kind you ask for the streams you need. Seems pretty OO if you ask me.

Do you prefer a global class side factory facade ?

Both approaches are not exclusive per se, we just want a clear break/difference (because the resulting streams are not 100% the same).

> (b) supports '/dev/stdin' and '/dev/stdout' as file names

Maybe, with special casing. I like 'Stdio stdout' better as it is more cross platform.

> (c) interprets the external type #'text' either as #'utf8' LC_CTYPE

Maybe, but that is not very Smalltalk like is it ? You want users to set environment variables ? Anyway this is less important point as UTF-8 is (should be) the general default.

> What document should I read to get a mental model of the new
> system and understand its rationale?

ML discussions over the year, I guess.

We are generally against big hairy complex classes and prefer simpler ones.