Re: [RFC] UString
| From: | Rowan Collins | Date: | Thu, 23 Oct 2014 13:44:46 +0000 |
| Subject: | Re: [RFC] UString | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78271@lists.php.net to get a copy of this message | ||
Dmitry Stogov wrote on 21/10/2014 10:01:
The "right" approach, would be extending zend_string with "encoding" and then adopting near all functions working with zend_string to take "encoding" into account. But, of course, this is going to lead to much more complicated solution (with some slowdown).Isn't that kind of what ext/mbstring does? I think that treating Unicode as nothing more than an encoding, and trying to hide all its complexity from the user, is not particularly wise. Unicode isn't just "ASCII, but bigger", so keeping the same API but making the implementation "work" with more characters isn't really "Unicode support". For instance, what does "allowing Unicode strings as array keys" actually mean? We already allow pretty much any sequence of bytes as an array key, so what we're actually talking about is that array-handling functions should be somehow "Unicode aware". In the case of sorting functions, that means a mechanism for selecting a collation, even if you know how the strings are encoded. There are a handful of operations which have an obvious meaning under Unicode - strtoupper(), for instance. It might be nice if those worked transparently with UStrings, but I don't think that really constitutes "complete Unicode support" either. I think we're going to keep going round in circles unless we can really pin down what it means for a language to "support Unicode". -- Rowan Collins [IMSoP]