Re: [VOTE] Locale-independent case conversion
| From: | Nicolas Grekas | Date: | Thu, 25 Nov 2021 09:58:41 +0000 |
| Subject: | Re: [VOTE] Locale-independent case conversion | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116504@lists.php.net to get a copy of this message | ||
Le jeu. 25 nov. 2021 à 10:47, Tim Starling <tstarling@wikimedia.org> a
écrit :
> On 25/11/21 7:55 pm, Nicolas Grekas wrote:
>
>
> I voted yes because I want to see this happen but I raised a point in
> https://externals.io/message/116141#116259 and didn't get
> an answer:
>
> Despite their name, I never used natcase functions for natural language
>> processing. I use them eg to sort lists of files in a directory, to
>> account
>> for numbers mainly. But that's not what I would call natural language
>> processing. I'm not aware of anyone using them for that actually. I'm
>> wondering if it's a good idea to postpone migrating them to an
>> hypothetical
>> future as to me, the whole reasoning of the RFC applies to them.
>>
>
> I wish the strnatcasecmp() and natcasesort() function, but also the
> SORT_NATURAL flag were also covered by this RFC.
> Is that possible? Would it make sense?
>
>
> I'm not going to migrate those functions at this time. It's just a project
> scope decision.
>
Why?
The RFC says:
> because they also use isdigit() and isspace(),
Does that mean "too much work needed"? I would totally understand that of
course but I hope someone could do these last miles.
> and because they are intended for natural language processing
I definitely do not agree with this argument and it should be removed from
the RFC to me as it might add confusion in the future.
Nicolas