[squeak-dev] Re: The future of Squeak & Pharo (was Re:
[Pharo-project] [ANN] Pharo MIT license clean)
Yoshiki Ohshima
yoshiki at vpri.org
Mon Jun 29 18:10:18 UTC 2009
At Mon, 29 Jun 2009 00:38:16 -0700,
Andreas Raab wrote:
>
> 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.
Right. And Phillippe can strip the leading char when he wants.
> >> 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.
From another POV, the communication with outside world was
secondary. The .changes in in UTF-8 but has the additional
information always so it is lossless.
> >> 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).
I should say I've been agreeing with it for a while, but it also is
a huge unstabilier to the existing system. Now Pharo people may be
able to leap the gap, if they like.
-- Yoshiki
More information about the Squeak-dev
mailing list
|