Okay, I can be convinced. :) Diff and RFC updated.
And I agree on the slight sense of unease at adding a third encoding converter, but ICU is so far ahead of the other two that I really feel we should encourage its use over iconv and mbstring. -Sara On Wed, Oct 31, 2012 at 6:40 PM, Adam Harvey <ahar...@php.net> wrote: > On 31 October 2012 06:18, Sara Golemon <poll...@php.net> wrote: >> With the exception of renaming the UConverter::UCNV_* constants to >> remove the UCNV_ prefix, I believe I've addressed the concerns thus >> far. ((Waiting to hear if anyone else wants to weigh in on the >> contants)) The RFC has been updated accordingly.+ > > I would say that unprefixing makes sense in general, particularly > since that's what happens in other intl classes (such as Collator). > Prefixing the callback reason constants with REASON_* seems like a > good compromise there — as you said upthread, they are different to > the other constants defined on UConverter. Beyond that, I think the > type constants would do fine as direct UConverter constants > (UConverter::UTF8, for instance, makes sense to me — in general, > you're using a converter because you want to deal with encoding > types). > > I'm +1 on the functionality in general. The thought of another > encoding conversion API in PHP doesn't fill me with great joy given we > already have mbstring and iconv, but it does provide features neither > of those libraries provide: combined with the existing intl > functionality and the ever-increasing need for internationalisation > support, I'd like to think we might look at nudging intl towards being > the usual way of providing that functionality in PHP. > > Thanks, > > Adam, who is apparently in a run-on sentence kind of mood today. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
