> On Aug 16, 2024, at 3:36 PM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > On 16 August 2024 19:44:22 BST, Mike Schinkel <m...@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? > > > 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.
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. 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 — if it is ever used in that way — 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. 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
