Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79159
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
Message-ID: <547466DA.9010808@gmail.com>
Date: Tue, 25 Nov 2014 11:24:10 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAESVnVpkEmCxL-hApFX=iidA+J3Aejw7ryDs1FjomUSkymQpNA@mail.gmail.com> <54745321.9020507@lsces.co.uk>
In-Reply-To: <54745321.9020507@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions
From: rowan.collins@gmail.com (Rowan Collins)

Lester Caine wrote on 25/11/2014 10:00:
> On 25/11/14 04:47, Sara Golemon wrote:
>> While playing around with Andrea's unicode literals syntax proposal, I
>> was reminded of just how little of ICU is exposed.  I've put up a
>> short proposal for adding IntlChar exporting these APIs as static
>> methods (with a matching non-oop interface).
>>
>> https://wiki.php.net/rfc/intl.char
> Isn't the problem here that while ICU is perhaps the obvious way
> forward, there is still no decision that it will be the base for other
> developments? Other proposals are looking for a lighter solution to the
> problem? I'd make a case for using the UTF8 configuration of ICU as the
> base for all the unicode developments, but can understand that this may
> not play well with other installations of ICU on a system?
>

I think this is just adding some functionality to the existing ext/intl 
[http://php.net/intl], which is basically a PHP wrapper around ICU 
already, so doesn't have much bearing on further Unicode developments.

-- 
Rowan Collins
[IMSoP]