Re: [Discussion] Should All String Functions Become Multi-Byte Safe?

From: Date: Sat, 17 Aug 2024 00:13:26 +0000
Subject: Re: [Discussion] Should All String Functions Become Multi-Byte Safe?
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-125012@lists.php.net to get a copy of this message
> 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. >> >> 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. > > Again, that's not really what I intended to say, but I'm probably not expressing > myself clearly. > > I was thinking about the way we frame the conversation, the words we focus on, and how that > shapes the conversation. > > 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. > > 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*. > > 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.

« previous php.internals (#125012) next »