Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84126
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
Message-ID: <54F3869E.9000208@gmail.com>
Date: Sun, 01 Mar 2015 21:37:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <1413875212.2624.3.camel@localhost.localdomain>	<CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>	<CAGKNXQEYquY_YQvTRv7uAhaycyCNG1FRwX_GYZ1dnHfhC-biZg@mail.gmail.com>	<54469840.3070708@sugarcrm.com>	<1414051917.2624.35.camel@localhost.localdomain>	<CA+9eiLsC1dD9vp=uWqdYTXj7hC=mBnOMSs5B6KFngOQPd1m4OA@mail.gmail.com>	<1414060726.2624.60.camel@localhost.localdomain>	<1414072403.3228.3.camel@kuechenschabe>	<87D717D5-273B-4A32-A3E5-83EBDFD314CB@ajf.me>	<1414077690.3228.12.camel@kuechenschabe>	<54495CF6.30608@sugarcrm.com>	<1414130585.2624.64.camel@localhost.localdomain>	<CAGAGxbaKK4P2D5epQTzEzNx3jcBP7XCPexGA4gyA3hdx3p+UKg@mail.gmail.com> <CAL=_i_nDz0XoVA5d4gqinYg9GinJUMW55+HLQ4y9O3Nj_URoxw@mail.gmail.com> <54F377D2.7030601@lsces.co.uk>
In-Reply-To: <54F377D2.7030601@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] UString
From: rowan.collins@gmail.com (Rowan Collins)

On 01/03/2015 20:34, Lester Caine wrote:
> On 28/02/15 06:48, Joe Watkins wrote:
>>      This is just a quick note to announce my intention to ready this RFC
>> for voting next week.
> Since there is nothing in this which needs any changes to the core then
> surly it simply needs to exist in pecl until such time as a proper
> replacement for unicode in core strings has been addressed? Since it
> will still require intl to provide those areas it does not support, and
> I question if we really need to provide yet another encoding converter.
>
> A unicode string handler that just handles UTF8 strings may be yet
> another stepping stone, but it still falls short of beings able to
> handle all of the internationalization problems and is simply an
> alternate to mbstring so one either runs both, or sit down and convert
> all the third party libraries to eliminate mbstring.
>
> Like http extension, it's not essential that it's loaded by default, and
> leaving it in pecl allows development outside that of the core?
>

I think this is probably a good idea at this stage. It will give people 
a chance to play around with it in an "experimental" state before 
committing to maintaining a particular API.

Since there's no real BC break here, there's no reason it couldn't be 
bundled into 7.1 if it was deemed ready by then, so it seems unwise to 
rush into including it in 7.0 straight from what feels like a prototype 
implementation.

Regards,

-- 
Rowan Collins
[IMSoP]