Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

[Bernd]

While we are at it, is Locale.ROOT character types guaranteed to only touch ASCII for case conversion, or could it use latin1 ranges, anyway? (Especially if we think compact strings). How about unassigned or illegal Code units?

Gruss

Bernd

--

http://bernd.eckenfels.net

 

---

Von: core-libs-dev <core-libs-dev-r...@openjdk.org> im Auftrag von Archie Cobbs <archie.co...@gmail.com>
Gesendet: Mittwoch, April 12, 2023 12:33 AM
An: Glavo <zjx001...@gmail.com>
Cc: Remi Forax <fo...@univ-mlv.fr>; core-libs-dev <core-libs-dev@openjdk.org>
Betreff: Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

 

On Tue, Apr 11, 2023 at 4:52 PM Glavo <zjx001...@gmail.com> wrote:

i'm not sure that the methods lowercase() and uppercase() are a good addition.

Their names are too close to toLowerCase/toUpperCase thus too easy to misuse ones for the others.

 

I'm fine with users having to write toLowerCase(Locale.ROOT) or toUpperCase(Locale.Root) because this is already what we teach.

This is the current situation, but I don't think it is good.

This idiom forces users to import Locale even in locale-insensitive scenarios. 

Possible compromise? How about toUpper() and toLower()?

This would be consistent with the trend whereby newer replacement names tend to be less verbose (e.g., Enumeration.hasMoreElements() -> Iterator.hasNext()), while also being different enough that people shouldn't mistake them for something that already exists, and will understand that they must mean something new.

-Archie

--

Archie L. Cobbs