Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
Message-ID: <54463F65.8070408@gmail.com>
Date: Tue, 21 Oct 2014 12:11:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <1413875212.2624.3.camel@localhost.localdomain>	<CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>	<1413883549.2624.22.camel@localhost.localdomain> <CA+9eiLtgP91eAPCS8vh+A2sijKhX8-sCKyU4axCDxbpLEcfkYw@mail.gmail.com> <54463347.6020002@lsces.co.uk>
In-Reply-To: <54463347.6020002@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)

Lester Caine wrote (on 21/10/2014):
> If we are going down the root of keeping PHP7 as ascii only in the core,
> then ustring probably makes sense, but it does not address many of the
> areas where unicode is really needed.

Just a quick point: most of the core is not ASCII. PHP strings are byte 
strings, completely divorced from any encoding. A few native functions 
assume ISO8859-1 (or possibly Windows CP1252), but mostly they just 
juggle which ever bytes you give them.

The main exception I can think of is that numbers are often handled 
specially, with digits and separators as defined by ASCII. But since 
we're talking UTF-8, that doesn't need to change.

> Handling unicode content outside
> the core is working reasonably at the moment, it is the problems such as
> using unicode keys for arrays which is the main area where unicoe is
> needed in PHP7 and so a more embedded handling is needed which may cut
> across yet another content wrapper?

I do think this is an important thing to consider, though. If this 
extension is genuinely just meant as a more modern and more performant 
way of doing things which mbstring and intl can already do, that needs 
to be clear in the way it's documented and publicised. If this gets 
publicised as "better Unicode support", users are naturally going to 
expect UString objects to start appearing in core, and in other 
extensions, and be disappointed that it's still just a toolbox for their 
own string handling.

-- 
Rowan Collins
[IMSoP]