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. I do agree that having yet another set of functions with their own behaviours isn't ideal, though. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
