Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119162
Message-ID: <9876abdf-a7af-0e53-ee3e-236021d74377@wikimedia.org>
Date: Fri, 16 Dec 2022 14:21:03 +1100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Content-Language: en-US
To: Derick Rethans <derick@php.net>,
 PHP Developers Mailing List <internals@lists.php.net>
References: <alpine.DEB.2.23.453.2212151531360.462551@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.23.453.2212151531360.462551@singlemalt.home.derickrethans.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Unicode Text Processing
From: tstarling@wikimedia.org (Tim Starling)

On 16/12/22 02:34, Derick Rethans wrote:
> Hi,
>
> I have just published an initial draft of the "Unicode Text Processing"
> RFC, a proposal to have performant unicode text processing always
> available to PHP users, by introducing a new "Text" class.

Using "collator" and "locale" interchangeably seems imprecise. If the 
input is an ICU locale string, then I think you should just call it 
locale. Then the user will be armed with the correct terminology when 
they go looking for more information in the ICU manual. In ICU, case 
conversion and BreakIterator need a locale, not a collator.

I'm concerned about the time order of using grapheme offsets. For 
example, is subString() O(N) in $offset? If the idea is to be easy to 
use and performant, you don't want to have subtle algorithmic 
complexity traps.

I'm probably not the target audience for this class, since I'm 
generally looking for maximum flexibility, not minimum complexity. As 
such, I'd like intl to have better documentation and more features. 
The RFC has a family of locale-aware case conversion functions which 
do not exist in intl. This was raised as an issue during the 
discussion on my ASCII case conversion RFC. It would be great if intl 
could get those functions too.

I think you should consider making this Text class a part of the intl 
extension. You're adding a class which is similar to the classes in 
that extension. In terms of data, it's like IntlChar, except it's for 
strings not characters. Its constructor takes an ICU locale string, 
just like IntlBreakIterator or MessageFormatter.

I can understand if you don't want to follow all the existing 
conventions of the intl extension. But if that is the rationale for 
the RFC, I'd like to see a discussion of the specific usability 
problems with the intl extension.

-- Tim Starling