Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79506
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54871CAA.6040600@lsces.co.uk>
Date: Tue, 09 Dec 2014 16:00:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <E21EA75D-69AA-408C-88B7-C8022E9FB2C7@ajf.me> <CADG7izVM1qVFQC9wp4An=sTn-VB-PSkSmUgNUiOFRsm9uGDF6A@mail.gmail.com> <10EE9A5B-1711-455A-AB6A-6E7EA858D081@ajf.me> <5486AFA3.3000402@lsces.co.uk> <FAD2C229-4AE8-49CC-8DA3-0180B796A784@ajf.me> <5486FA8B.2070206@lsces.co.uk> <07B2909B-359D-401E-B9CC-DAC0E8F22B19@ajf.me> <5487104E.7020201@lsces.co.uk> <54871578.6050202@gmail.com>
In-Reply-To: <54871578.6050202@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE][RFC] Unicode Codepoint Escape Syntax
From: lester@lsces.co.uk (Lester Caine)

On 09/12/14 15:30, Rowan Collins wrote:
> Lester Caine wrote on 09/12/2014 15:07:
>> On 09/12/14 14:07, Andrea Faulds wrote:
>>>> On 9 Dec 2014, at 13:35, Lester Caine <lester@lsces.co.uk> wrote:
>>>>
>>>>> On 09/12/14 13:07, Andrea Faulds wrote:
>>>>>
>>>>>> On 9 Dec 2014, at 08:15, Lester Caine <lester@lsces.co.uk> wrote:
>>>>>>
>>>>>> If ICU is to be adopted as the base for unicode support, then surely
>>>>>> everything else should follow those rules?
>>>>>> \uhhhh and \Uhhhhhhhh are defined along with \x{hhhhhh} so does it
>>>>>> make
>>>>>> sense to add something which is not part of ICU?
>>>>> Er, where does ICU define \uXXXX and \UXXXXXX? I don't unferstand.
>>>> http://userguide.icu-project.org/strings/regexp
>>> We aren't using ICU regular expressions, and ICU is merely an
>>> implementation detail anyway.
>> Has THAT been agreed on? Surely if using ICU fully in PHP7 in place of
>> the patchwork of current fixes for unicode then we don't want to be
>> breaking thing again by odd differences from the core code for unicode?
>> I though the agreement was that there was no resource to create an
>> alternative from scratch?
> 
> I think what Andrea's getting at is that the fact that ICU is in use
> under the hood shouldn't be particularly visible to users. If PHP gets
> "Unicode support" (whatever that turns out to mean), what the user
> should see is *PHP's Unicode facilities*; only core devs and package
> maintainers will need to know that those are implemented using ICU. As
> such, there's no automatic need for PHP to do everything the same way as
> ICU.

That was the reason for asking ...
What is the point of all these piecemeal patches when the underlying
base has not yet been agreed on? That we are using ICU in things like
the database interfaces for unicode support would point to it being
somewhat useful if those processes produced the same code as the same
actions in PHP. ICU is well established and it's API already in use in
the same platform as PHP is running on ... so can we please treat all of
these 'patches' in the light of a proper debate on the bigger picture.
Forcing something like this through now simply does not make sense, and
while there may be no 'automatic need' for the database interface to
work the same as other parts, it would perhaps be worth a little
consideration?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk