On 06/30/2009 12:02 AM, Yoshiki Ohshima wrote:
> At Mon, 29 Jun 2009 11:13:24 +0200,
> Paolo Bonzini wrote:
>> You're free to have your opinion on Han unification.  Many people share
>> it, many people don't.  But the fact is, only Squeak does it this way
>> and it does have as many problems as it solves.
>>
>> For another way to encode languages see
>> http://www.isi.edu/in-notes/rfc2482.txt.
>
>    As Eliot wrote, an interactive environment has different constraint.
> #at: is one of them, and $- notation for specifying a character
> etc. (say print-it for it should print something) should provide some
> workable solution.

#at: is not one of them, language tags should not be skipped just like 
soft hyphens (U+00AD, also known as hyphenation hint) should not. 
Regarding specifying a character, I don't think it happens *so* often 
that a Japanese wants to specify explicitly a Chinese shape and vice 
versa for a single character.  Just choose a default font based on the 
current local, and for the occasional time when you do know the language 
use something like this:

    String>>withLanguageTag: aString
        ^(Character codePoint: 16rE0001) asString,
	(aString collect: [:ch|Character codePoint: ch value+16rE0000]),
	self

    Character>>withLanguageTag: aString
       ^self asString withLanguageTag: aString

    (Character codePoint: 16r4000) withLanguageTag: 'JAPANESE'

>    I think a future version basically shouldn't try to "print" a
> Chararacter, but print out the code point and to display a character,
> you do have to supply the extra infomation.  (Character object is
> convenient, but you can go with all String objects, if you like.)

Exactly my point.  When you know a language you can go with String 
objects and then you can avoid #leadingChar.

Paolo