Re: [Discussion] Should All String Functions Become Multi-Byte Safe?
| From: | Mike Schinkel | 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.