> Am 26.07.2018 um 17:59 schrieb Sven Van Caekenberghe <s...@stfx.eu>:
>
> 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.
>
+1
Norbert
> 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.
>>
>>
>>
>
>
