Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125007
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV][Discussion] Should All String Functions Become
 Multi-Byte Safe?
In-Reply-To: <BC11D97A-F56E-4C22-ABCE-C4A44680BCA7@rwec.co.uk>
Date: Fri, 16 Aug 2024 19:25:13 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <37013714-371C-4871-9E15-FE91657A662B@newclarity.net>
References: <CAPn3h8LunRRAEfQXbfuDzMsxwGeFZfsHXs7oB=DTMhN2fgphUg@mail.gmail.com>
 <1AFE8300-D363-43D8-A989-15D001B9879C@newclarity.net>
 <dc2d9656-557a-4bf2-9971-245b30b1aa30@rwec.co.uk>
 <270D6057-626D-4720-B44A-3CB7A7B9320B@newclarity.net>
 <BC11D97A-F56E-4C22-ABCE-C4A44680BCA7@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

> On Aug 16, 2024, at 3:36 PM, Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk> wrote:
> On 16 August 2024 19:44:22 BST, Mike Schinkel <mike@newclarity.net> =
wrote:
>> Let me see if I understand your argument correctly?  You are =
asserting that Unicode is "too complex" to be handled in the standard =
library so that complexity should instead be shouldered individually by =
each and every PHP developer who needs to work with Unicode text in PHP, =
which is many PHP developers if not eventually most. Is that your =
argument?
>=20
>=20
> Not really, no. I'm definitely in favour of including more =
Unicode-based string handling functionality, by improving and extending =
ext/intl, or coming up with new convenience wrappers for common tasks.=20=


Your prior reply came across to me as a closed-end slamming-the-door on =
the topic because of "what we can't do," which is why I commented on.

This most recent reply OTOH was an example of exploring "what we can do" =
to improve PHP. So kudos for this reply; big plus.

> What I'm always sceptical of is the idea that you could ever consider =
such functionality "complete", or that "Unicode support" can ever be a =
single deliverable, rather than an ongoing aspiration. (And =
consequently, I'm sceptical of any language which says it has achieved =
that.)

To be clear I don't think anything can ever be considered "complete" =
unless you are talking something as limited in scope as numeric =
addition. And even then, supporting imaginary numbers might arise. =20

So while it is not a problem to be explicit about it even if redundant, =
having it be an underlying reason to argue against useful functionality =
=E2=80=94 if it is ever used in that way =E2=80=94 seems =
counter-productive. Nothing precludes a follow-up RFC after an initially =
successful RFC is implemented and shipped.

> I also think "Unicode support" is probably the wrong angle to approach =
from; it leads to features like IntlChar, which technically provides =
access to tons of data from the Unicode standard, but practically has no =
use for 99% of PHP developers. Instead we should be talking about =
"internationalisation support", of which handling different writing =
systems is one (fairly big) part.

I am not sure I agree with you that adding Unicode support is the wrong =
angle, per se.=20

A strong argument could be made that Unicode support is a necessary but =
not sufficient building block for "internationalization support."  IOW, =
if you want to get to the latter it is probably a lot easier to start =
with the former as the scope of the latter is by-nature larger. After =
all, perfect is the enemy of the good and waiting for a full-press =
effort for internationalization support could well push off Unicode =
support long down the road.

Still, *if* "full" internationalization support can be achieved in the =
shorter term it would be bikeshedding for me to argue against it.

-Mike