From: Magnus Holm Date: 2011-03-18T19:53:56+09:00 Subject: [ruby-core:35524] Re: [Feature #2350](Rejected) Unicode specific functionality on String in 1.9 --90e6ba180dd42a060f049ebf9698 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The problem is that the definition of #upcase doesn't only depend on the encoding used, but also the language of the encoded text. For instance, if you're writing in Turkish, you would expect "i".upcase to return a dotted uppcase I: http://www.i18nguy.com/unicode/turkish-i18n.html Doing this properly is *really* hard and needs to have a lot of flexibility, especially when it comes to non-Western languages. It's far easier for everyone that the built-in #upcase is simple and fast and you'll have to be explicit about an= y other I18n stuff IMO. // Magnus Holm On Fri, Mar 18, 2011 at 11:19, Nikolai Weibull wrote: > On Thu, Mar 25, 2010 at 19:33, Nikolai Weibull wrote: > > On Thu, Mar 25, 2010 at 18:24, NARUSE, Yui wrote: > >> (2010/03/26 0:02), Nikolai Weibull wrote: > > > I was wondering if there was a way to do it without having to do > > > > String.new.unicodify.upcase > > >> But I think, people want both ASCII version and Unicode version of > upcase. > >> So you should name your Unicode methods another names. > > > Why would they want that? Having an ASCII-only version of #upcase > > makes no sense for a Unicode String more than supporting #upcase > > requires that you load the Unicode character database information, > > which takes up quite a lot of memory. > > So, what=E2=80=99s the reasoning here? Having "=C3=A4bc".upcase return "= =C3=A4BC" makes > absolutely no sense and means that quite a few methods on String are > completely useless in a m18n context. > > --90e6ba180dd42a060f049ebf9698 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The problem is that the definition of #upcase doesn't only depend on th= e encoding used, but also the language of the encoded text. For instance, i= f you're writing in Turkish, you would expect "i".upcase to r= eturn a dotted uppcase I:=C2=A0http://www.i18nguy.com/unicode/turkish-i18n.html

Doing this properly is *really* hard and needs to have a lot of=C2=A0f= lexibility, especially when it comes to non-Western languages. It's far= easier for everyone that the built-in #upcase is simple and fast and you&#= 39;ll have to be explicit about any other I18n stuff IMO.

// Magnus Holm


On Fri, Mar 18, 2011 at 11:19, Nikolai W= eibull <now@bitwi.se> wrote:
On Thu, Mar 25, 2010 at 19:33, Nikolai Weibull <now@bitwi.se> wrote:
> On Thu, Mar 25, 2010 at 18:24, NARUSE, Yui <naruse@airemix.jp> wrote:
>> (2010/03/26 0:02), Nikolai Weibull wrote:

> I was wondering if there was a way to do it wi= thout having to do
>
> String.new.unicodify.upcase

>> But I think, people want both ASCII version and Unicode version of= upcase.
>> So you should name your Unicode methods another names.

> Why would they want that? =C2=A0Having an ASCII-only version of #upcas= e
> makes no sense for a Unicode String more than supporting #upcase
> requires that you load the Unicode character database information,
> which takes up quite a lot of memory.

So, what=E2=80=99s the reasoning here? =C2=A0Having "=C3=A4bc&qu= ot;.upcase return "=C3=A4BC" makes
absolutely no sense and means that quite a few methods on String are
completely useless in a m18n context.


--90e6ba180dd42a060f049ebf9698--