[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 06:30:21 UTC 2009
At Mon, 29 Jun 2009 07:18:11 +0200,
Philippe Marschall wrote:
>
> 2009/6/29 Yoshiki Ohshima <yoshiki at vpri.org>:
> > At Sun, 28 Jun 2009 19:28:50 +0200,
> > Philippe Marschall wrote:
> >>
> >> For Seaside #leadingChar is a PITA because there is no way of knowing
> >> the language of the content the user entered. And it's a rampant
> >> layering violation. And it probably contributes to WideStrings being
> >> so slow. And it's not portable. And ....
> >
> > For Seaside you don't need to display the string so you can just
> > ignore it.
>
> Nope, because in Seaside sometimes we like to compare strings and
> #leadingChar is taken into account for #=. And we have to write code
> that runs on other systems.
Yeah, but insisting to use #= to do it seems to be a wrong goal
Define seasideEqual: and use it elsewhere would be better.
> And we have to map characters to bytes and bytes to characters.
Everybody does. Not sure why it is relevant.
> >> And don't get me "but we need it for fonts". The only way to get nice
> >> fonts in Squeak is to avoid it and do it in C with char*.
> >
> > This is a very confused statement. You better pass the font and
> > language information to the outside renderer to get the proper result.
>
> 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.
-- Yoshiki
More information about the Squeak-dev
mailing list
|