On 20/06/2019 23:30, Mark Randall wrote:
There does at least seem to be the starting point in that mb_string is
already widely used, and my suggestion that it "work as expected" is
more that it would work as the equivalent mb_string / iconv function
would.
I think this is a rather short-sighted way of looking at it. If people
want the API provided by the mbstring extension, they can just use those
functions; the advantage of designing a new set of functions is surely
that we don't need to stick to past decisions. If we start to build a
new standard library, as Zeev suggested in the deprecation thread, it is
a once-in-a-lifetime chance to build something better, not just copy
what's gone before.
mb_strlen returns the number of codepoints for example, I'm not
immediately seeing anything about mb_string supporting Graphemes as
the only reference I could find to their manipulation was The intl
extension.
The mbstring extension was not built for Unicode, but for older Japanese
multi-byte encodings, where the definition of "character" is much more
straight-forward. Its Unicode support seems to mostly see code points as
mappings for characters in some other encoding. (The oldest manual page
for it on archive.org [1] is from 2001, and includes the quaint remark
"As Unicode is getting popular, UTF-8 is used also.") The iconv library
is even more explicitly aimed at converting between character sets,
rather than understanding them (the extra functions such as iconv_strlen
are unique to PHP).
Unicode today is much more than a mapping of legacy encodings to a
universal character set, and I can think of no useful purpose in
declaring the "string length" of the British flag emoji to be 2, just
because it is encoded as the sequence U+1F1EC U+1F1E7.
[1]
http://web.archive.org/web/20010605075550/http://www.php.net/manual/en/ref.mbstring.php
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
