[squeak-dev] Re: The future of Squeak & Pharo (was Re:
[Pharo-project] [ANN] Pharo MIT license clean)
Andreas Raab
andreas.raab at gmx.de
Mon Jun 29 07:38:16 UTC 2009
Yoshiki Ohshima wrote:
> Yeah, but insisting to use #= to do it seems to be a wrong goal
> Define seasideEqual: and use it elsewhere would be better.
You'd have to change too many places for this to be feasible. For
example, consider Set and Dictionary operations which may have to be
changed in this process.
>> And we have to map characters to bytes and bytes to characters.
>
> Everybody does. Not sure why it is relevant.
Because a simple conversion like squeakToUtf8/utf8ToSqueak is not
lossless anymore. The problem is that Unicode is Unicode is Unicode ;-)
You can either use it and live with its shortcomings or you can write
something completely different. But as soon as one tries to redefine it
partially it leads to problems since there are too many surrounding
assumptions.
>> I agree but you don't know how often I have gotten this answer when I
>> suggested to simply drop #leadingChar.
>
> Maybe you get the answer often because it makes sense? I wrote this
> a few times in last some years but if the goal is to make a
> comprehensible personal computer environment, some information is
> needed more than Unicode code points provides.
Yes, but it is not clear whether that information belongs into the
string itself or in its surrounding context. The argument that a
language should be part of the string itself can certainly be made but
it neglects the necessity of interacting with the outside world. And in
the outside world (meaning Unicode) the language tag isn't part of the
string but rather part of the context. Consequently, I think that Squeak
should follow similar semantics (imperfect as that may be for some uses)
and have language information associated with class Text (i.e., a text
attribute) not with class Character (leadingChar).
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|