[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