Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125012
Content-Type: text/plain;
	charset=us-ascii
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: <BC87D2FF-0524-49DD-9D23-3D4229DF034A@rwec.co.uk>
Date: Fri, 16 Aug 2024 20:13:26 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <177155F3-8D62-4F5A-A908-0D0F717DFF1B@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>
 <37013714-371C-4871-9E15-FE91657A662B@newclarity.net>
 <BC87D2FF-0524-49DD-9D23-3D4229DF034A@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

> On Aug 16, 2024, at 8:02 PM, Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk> wrote:
> On 17 August 2024 00:25:13 BST, Mike Schinkel <mike@newclarity.net> =
wrote:
>> I am not sure I agree with you that adding Unicode support is the =
wrong angle, per se.=20
>>=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.
>=20
> Again, that's not really what I intended to say, but I'm probably not =
expressing myself clearly.
>=20
> I was thinking about the way we frame the conversation, the words we =
focus on, and how that shapes the conversation.
>=20
> The example that keeps coming to mind is =
password_hash/password_verify. It seems to me that for years, the =
conversation was framed around "cryptographically safe hashing =
functions", and teaching users why and how to use powerful but confusing =
functions like hash() and crypt(). Then it got reframed from the point =
of view of a web developer wanting to implement logins, and we ended up =
with fantastically easy to use functions.=20
>=20
> In the same way, I think "Unicode support" should be the awkward =
background work that we do *because we're trying to solve specific =
problems involving text*.=20
>=20
> In the case of this thread, I think the actual user story is "I want =
to allow users to enter a wide range of characters, but restrict them in =
contextually appropriate ways to ensure various types of safety and =
security". The implementation of that involves a lot of technicalities =
about how Unicode works, but ideally we want to find meaningful =
abstractions of those technicalities, not just require every user to =
understand them.

We are in no real disagreement there.

-Mike

P.S. I do think we could reach the same end-goal by taking either =
direction since Unicode support is a building block of solving specific =
problems involving text, and thus needs to happen either way.

But, as I implied earlier, whichever road takes us there works for me so =
no need for me to further bikeshed it, as long as the road we take will =
not result in a dead-end.=