From: Julian 'Julik' Tarkhanov <listbox@...>
Date: 2006-06-17T23:14:03+09:00
Subject: Re: Unicode roadmap?


On 17-jun-2006, at 15:52, Austin Ziegler wrote:
>> 8. Because Strings are tightly integrated into the language with the
>> source reader and are used pervasively, much of this cannot be
>> provided by add-on libraries, even with open classes. Therefore the
>> need to have it in Ruby's canonical String class. This will break  
>> some
>> old uses of String, but now is the right time for that.
>
> "Now" isn't; Ruby 2.0 is. Maybe Ruby 1.9.1.

Most probably wise, but I need casefolding and character classes to  
work since yesteryear.
Oniguruma is there but even if you complie with it (which is not the  
default, still) you don't get char classes (AFAIK)
and you don't get casefolding. Case-insensitive search/replace  
quickly becomes bondage.

I am maintaining a gem whose test fails due to different regexps in  
Oniguruma, but I would be able to quickly fix it knowing that  
Oniguruma is in stable now.
>> 10. Be flexible. <placeholder for future idea>
>
> And little is more flexible than Matz's m17n String.

I couldn't find a proper description of that - as I told already, the  
thing I'd least prefer would be

# get a string from the database
p str + my_unicode_chars # Ok, bail out with an ugly exception  
because the author of the DB adaptor didn't care to send me proper  
Strings...

If strings in the system are allowed to have varying encodings, I  
don't understand how the engine is going to upgrade/downgrade strings  
automatically.
Especially remembering that the receiver is on the left, so I  
actually might get different exceptions going as I do

p my_unicode_chars + mojikyo_str # who wins?

or

p mojikyo_str + my_unicode_chars # who wins?

or (especially)

p mojikyo_str +  
bytestring_that_i_just_grabbed_by_http_and_i_know_it_is_mojikyo_but_its_ 
not # who wins?

--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl