Richard, I am only engaging in a discussion with you in order to explain what we did and why. The changes that we did were years in the making and are now being pushed into the system. The discussions happened long ago, we are not going to revert them.
Of course you are entitled to have your own opinion and disagree. I do not know what 'your system' is that you are referring to. Pharo has a particular philosophy that includes a complex relationship with the concepts of Smalltalk and especially ANSI Smalltalk. In one sentence, we want to have to liberty to make (breaking) changes and don't want to be stuck in the past. At the same time we want our user base to be able to follow by adapting their code. Regards, Sven > On 26 Jul 2018, at 17:06, Richard O'Keefe <rao...@gmail.com> wrote: > > 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. > > >
