Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84129
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54F3869E.9000208@gmail.com>
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> <54F3869E.9000208@gmail.com>
Date: Mon, 2 Mar 2015 07:14:42 +0900
Message-ID: <CAGa2bXa8uUzyqsFaByp_Y-KaKoR41WAc2a9CyMWXWuxznw4dpw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c16884141d1a0510417057
Subject: Re: [PHP-DEV] [RFC] UString
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c16884141d1a0510417057
Content-Type: text/plain; charset=UTF-8

Hi Joe and Rowan,

On Mon, Mar 2, 2015 at 6:37 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> 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.


Sounds reasonable.

Joe, I don't have much time to help, but I'm willing to help UString
development.
I think it's better to keep it simple. Having unified internal encoding
(NFC normalized
UTF-8 string without BOM) for internal string representation would be much
simpler
than multiple encodings.

We may consider various issues/ideas like this in relatively long term.
http://websec.github.io/unicode-security-guide/character-transformations/
http://docs.parrot.org/parrot/latest/html/docs/pdds/pdd28_strings.pod.html

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c16884141d1a0510417057--