hi Adam! On Mon, May 27, 2013 at 6:39 PM, Adam Harvey <ahar...@php.net> wrote: > On 26 May 2013 21:05, Stas Malyshev <smalys...@sugarcrm.com> wrote: >> >>> I agree with Nikita — I'm not against adding more Unicode/charset >>> handling functions if they make sense (and I haven't looked at the >>> code for this particular proposal yet), particularly if they'd be part >>> of a default build, but enough water has hopefully passed under the >> >> Did you mean "would *not* be part of the default build"? Because having >> yet another way of handling utf-8 (also basing on yet another separate >> library so with potential for incompatibilities and quirks) doesn't look >> like a good idea. Having yet another PECL ext is not a big deal, but >> having yet another way by default certainly would only create confusion. > > I did mean would — one issue with much of our internationalisation > code is that it's in extensions (intl, iconv, mbstring) that are > inconsistently deployed by shared hosting providers. Having some basic > conversion and string handling functions that could be available in > ext/standard might not be a bad thing.
We will still require to use some external Unicode data. I won't go with our own data set, ever, that's something we won't be able to maintain. By the way, it is why intl is very good, same APIs, it only adds new functions, no change in existing APIs, but you get free Unicode data update while updating the library. And I would like to enable it by default, or make it a required extension at some point. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
