--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 18, 2011 at 09:52:27PM +0900, Nikolai Weibull wrote:
> On Fri, Mar 18, 2011 at 11:53, Magnus Holm <judofyr / gmail.com> wrote:
> > It's far easier for everyone that the built-in #upcase is
> > simple and fast and you'll have to be explicit about any
> > other I18n stuff IMO.
>
> Easy, perhaps, but hardly useful.

A agree - for human interaction it is completely useless. I tend to
think of #upcase as just a convenience method for dealing with ASCII
only system level functionality, e.g. paths on filesystems,
environment variables, html tags, (un)capitalizing to get class names,
database table names, etc.

Anything else is "no-op" or "undefined" for me.

> My point is that the current #upcase (and similar methods) is
> basically useless for anything other than ASCII.

I would probably go one step further and disallow upcase and friends
for any non-US-ASCII string for this reason. At least issue a warning.

> If this isn=E2=80=99t of interest, then I=E2=80=99m still looking for a w=
ay to
> override #upcase for Strings that use the UTF-8 encoding without
> resorting to alias_method or extend (as shown earlier in this
> discussion).  This seems impossible to do at the moment, as Encoding
> is a completely opaque object.

Correct me if I am wrong, but even "upper case" as a concept is not
common among all languages - an implementation detail for specific
cases at best.

For example, in German, you may want a more meaningful 'to_noun'
instead of 'capitalize'. For Japanese some may want upcase as a no-op
and some as a hack to convert to katakana. For case insensitivity,
probably a "normalize" method would be more descriptive.

Out of curiosity: in what specific case is utf upcase necessary?

--=20
Cezary Baginski

--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk2I3HYACgkQgEYXSknSpI+ivgCfT6iutvk3d0w0NsCdQBxYc5sn
UIgAoJY4j4x3EChNJpnNZUR5csMQJRUG
=XbZH
-----END PGP SIGNATURE-----

--FCuugMFkClbJLl1L--

On Fri, Mar 18, 2011 at 09:52:27PM +0900, Nikolai Weibull wrote:
> On Fri, Mar 18, 2011 at 11:53, Magnus Holm <judofyr / gmail.com> wrote:
> > It's far easier for everyone that the built-in #upcase is
> > simple and fast and you'll have to be explicit about any
> > other I18n stuff IMO.
>
> Easy, perhaps, but hardly useful.

A agree - for human interaction it is completely useless. I tend to
think of #upcase as just a convenience method for dealing with ASCII
only system level functionality, e.g. paths on filesystems,
environment variables, html tags, (un)capitalizing to get class names,
database table names, etc.

Anything else is "no-op" or "undefined" for me.

> My point is that the current #upcase (and similar methods) is
> basically useless for anything other than ASCII.

I would probably go one step further and disallow upcase and friends
for any non-US-ASCII string for this reason. At least issue a warning.

> If this isn”Ēt of interest, then I”Ēm still looking for a way to
> override #upcase for Strings that use the UTF-8 encoding without
> resorting to alias_method or extend (as shown earlier in this
> discussion).  This seems impossible to do at the moment, as Encoding
> is a completely opaque object.

Correct me if I am wrong, but even "upper case" as a concept is not
common among all languages - an implementation detail for specific
cases at best.

For example, in German, you may want a more meaningful 'to_noun'
instead of 'capitalize'. For Japanese some may want upcase as a no-op
and some as a hack to convert to katakana. For case insensitivity,
probably a "normalize" method would be more descriptive.

Out of curiosity: in what specific case is utf upcase necessary?

-- 
Cezary Baginski
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk2I3HYACgkQgEYXSknSpI+ivgCfT6iutvk3d0w0NsCdQBxYc5sn
UIgAoJY4j4x3EChNJpnNZUR5csMQJRUG
=XbZH
-----END PGP SIGNATURE-----