From: Dmitrii Dimandt <dmitriid@...>
Date: 2006-06-19T22:46:22+09:00
Subject: Re: Unicode roadmap?

On 6/19/06, Austin Ziegler <halostatue@gmail.com> wrote:
> On 6/19/06, Dmitrii Dimandt <dmitriid@gmail.com> wrote:
> > I wonder. Why cannot Strings throughout Ruby be _always_ represented
> > as Unicode and why no let ICU handle the conversion between various
> > encodings for incoming and outgoing data?
> > (http://www.ibm.com/software/globalization/icu/). I know, it is a
> > long-stanbding issue on Unicode's Han unification process, but without
> > proper Unicode support Ruby is destined to be a toy for
> > English-speaking and Japanese communities only. (And as I'm gearing up
> > to prepare a web-site in Russian, Turkish and English, I feel that
> > using Ruby could prove to be a major pain in the nether regions of my
> > body :) )
>
> This entire discussion is centered around a proposal to do exactly
> that. There are many *very good* reasons to avoid doing this. Unicode
> Is Not Always The Answer.
>
> It's *usually* the answer, but there are times when it's just easier
> to work with data in an established code page.
>

I totally agree with that. IMO, the point lies exactly in this
"*usually* an answer". What was the last time 90% of developers had to
wonder what encoding their data was in ;-) And with the advent of
Unicode (and storage becoming cheaper and cheaper and developers
becoming more and more lazy and lazy) more and more of that data is
going to be Unicode.

So, since Unicode is *usually* the answer, make it as painless as
possible. Make all String methods and any other functions that work
with strings accept Unicode straight out of the box without any
worries on the developer's part. And provide alternatives (or optional
parameters?) that would allow the few more encoding-aware gurus :) do
whatever they want with encodings.

Because otherwise we are in a risk of ending up with incompatible
extensions to strings that "simplfy" a developer's life (and the
trend's already begun). I wouldn't want a C/C++ scenario with a string
class upon string class upon extension upon extension that aim to do
something String should do from the start.

All is IMHO, of course :)