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 <s...@stfx.eu> wrote: > > > > On 23 Jul 2018, at 18:52, Richard O'Keefe <rao...@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. > > >
