Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124990
Feedback-ID: id5114917:Fastmail
Date: Fri, 16 Aug 2024 20:36: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: <270D6057-626D-4720-B44A-3CB7A7B9320B@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>
Message-ID: <BC11D97A-F56E-4C22-ABCE-C4A44680BCA7@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 16 August 2024 19:44:22 BST, Mike Schinkel <mike@newclarity=2Enet> wrot=
e:
>Let me see if I understand your argument correctly?  You are asserting th=
at Unicode is "too complex" to be handled in the standard library so that c=
omplexity should instead be shouldered individually by each and every PHP d=
eveloper who needs to work with Unicode text in PHP, which is many PHP deve=
lopers if not eventually most=2E Is that your argument?


Not really, no=2E I'm definitely in favour of including more Unicode-based=
 string handling functionality, by improving and extending ext/intl, or com=
ing up with new convenience wrappers for common tasks=2E=20

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 d=
eliverable, rather than an ongoing aspiration=2E (And consequently, I'm sce=
ptical of any language which says it has achieved that=2E)

I also think "Unicode support" is probably the wrong angle to approach fro=
m; 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=2E Instead we should be talking about "internationalisat=
ion support", of which handling different writing systems is one (fairly bi=
g) part=2E

For instance, I would welcome proposals like "here's some functions for ha=
ndling locale-specific case folding and normalisation-based matching", "her=
e's some functions for limiting the storage size of a string without produc=
ing garbage characters", etc=2E As well as related things which aren't just=
 about text encoding, like "here's some functions for working with locale-s=
pecific date formatting" (or even just "here's some documentation for how y=
ou're supposed to use ext/intl's date classes")=2E


>> We also have the "mbstring" extension, =2E=2E=2E
>
>Interesting historical factoid, but how is that really relevant to includ=
ing Unicode into the standard library?

I was just summarising the current situation, to work out where we could g=
o next=2E Any attempt to extend string handling functionality is likely to =
build on either ext/intl or ext/mbstring, so it's useful to understand how =
they differ=2E


Regards,
Rowan Tommins
[IMSoP]