Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119155
Message-ID: <60ba972f-5b7c-f9ea-fb07-7b565bd108cd@bastelstu.be>
Date: Thu, 15 Dec 2022 19:16:36 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Andreas Heigl <andreas@heigl.org>, internals@lists.php.net
References: <alpine.DEB.2.23.453.2212151531360.462551@singlemalt.home.derickrethans.nl>
 <09aa499b-f5ec-5e80-63d8-6271fa87c390@heigl.org>
In-Reply-To: <09aa499b-f5ec-5e80-63d8-6271fa87c390@heigl.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Unicode Text Processing
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 12/15/22 17:05, Andreas Heigl wrote:

> I see a few challenges in the approach. My first question was: Why do we
> need a new implementation of the ICU library? Creating a userland
> 
> […]
> 
> I'm ambivalent about this. On the one hand it could make some things for
> sure easier. On the other hand it adds burden onto the core-developers
> that could be avoided by providing the intl (and mb-string) extension by
> default instead of having to add them separately. And then find a group
> if people willing to build a userland implementation.

Because a programming language needs a standard library, otherwise one 
could just use JavaScript and pull in a dependency for 'is-odd' or 
left-padding.

The biggest advantage this proposal has compared to ext/intl is that it 
*adds a new data type*. If you receive a 'Text' object then you are 
guaranteed to have valid Unicode/UTF-8 inside of it.

It also provides a OO API around text/string processing functionality, 
which is something users have desired for quite some time already 
("scalar objects").

The addition of a new data type is also a reason why this cannot 
usefully be implemented in userland alone: It would require every 
developer to standardize on a single userland implementation, as 
otherwise you need bridges to convert between the different 
representations of various userland libraries (or need to round-trip 
through the standard 'string' type), which I consider to be a 
non-starter for something as fundamental as text processing. Both 
because it adds complexity and because it will kill performance.

As the RFC notes, an explicit design goal is to keep the API simple and 
focused, so I don't expect much ongoing maintenance burden here. 
Especially if all the heavy lifting is off-loaded to ICU. Any 
convenience functionality can then be be provided in userland based on 
the building blocks provided by PHP itself, with the benefit that 
userland libraries are going to be fully interoperable because they all 
use the standard 'Text' type that is guaranteed to be available [1].

Best regards
Tim Düsterhus

[1] The 'Text' class should likely be made final, because folks might 
otherwise rely on a specific userland extension, preventing actual 
interoperability.