Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125011
Feedback-ID: id5114917:Fastmail
Date: Sat, 17 Aug 2024 01:02:59 +0100
To: internals@lists.php.net
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D=5BDiscussion=5D_Should_All_S?=
 =?US-ASCII?Q?tring_Functions_Become_Multi-Byte_Safe=3F?=
User-Agent: K-9 Mail for Android
In-Reply-To: <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> <37013714-371C-4871-9E15-FE91657A662B@newclarity.net>
Message-ID: <BC87D2FF-0524-49DD-9D23-3D4229DF034A@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 17 August 2024 00:25:13 BST, Mike Schinkel <mike@newclarity=2Enet> wrot=
e:
>I am not sure I agree with you that adding Unicode support is the wrong a=
ngle, per se=2E=20
>
>A strong argument could be made that Unicode support is a necessary but n=
ot sufficient building block for "internationalization support=2E"  IOW, if=
 you want to get to the latter it is probably a lot easier to start with th=
e former as the scope of the latter is by-nature larger=2E After all, perfe=
ct is the enemy of the good and waiting for a full-press effort for interna=
tionalization support could well push off Unicode support long down the roa=
d=2E

Again, that's not really what I intended to say, but I'm probably not expr=
essing myself clearly=2E

I was thinking about the way we frame the conversation, the words we focus=
 on, and how that shapes the conversation=2E

The example that keeps coming to mind is password_hash/password_verify=2E =
It seems to me that for years, the conversation was framed around "cryptogr=
aphically safe hashing functions", and teaching users why and how to use po=
werful but confusing functions like hash() and crypt()=2E Then it got refra=
med from the point of view of a web developer wanting to implement logins, =
and we ended up with fantastically easy to use functions=2E=20

In the same way, I think "Unicode support" should be the awkward backgroun=
d work that we do *because we're trying to solve specific problems involvin=
g text*=2E=20

In the case of this thread, I think the actual user story is "I want to al=
low users to enter a wide range of characters, but restrict them in context=
ually appropriate ways to ensure various types of safety and security"=2E T=
he implementation of that involves a lot of technicalities about how Unicod=
e works, but ideally we want to find meaningful abstractions of those techn=
icalities, not just require every user to understand them=2E


(PS I think I accidentally called you Rob just now; sorry!)
Rowan Tommins
[IMSoP]