[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