Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73095
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <53210857.5040908@googlemail.com>
References: <531EE602.3090207@lsces.co.uk> <531EEE2A.2000602@googlemail.com>
 <531F0146.5010701@lsces.co.uk> <53202DC5.4010306@googlemail.com>
 <532033E1.60602@lsces.co.uk> <53203687.7090405@googlemail.com>
 <532037F4.6020204@googlemail.com> <CAEZPtU5G41OKb2FQF4ajKgszATqtwxL9E_k4Zc78RZGL8B4qnQ@mail.gmail.com>
 <532049BB.2080605@lsces.co.uk> <53204C6B.3000506@googlemail.com>
 <5320511A.7040606@lsces.co.uk> <5320F554.5000109@lerdorf.com> <53210857.5040908@googlemail.com>
Date: Thu, 13 Mar 2014 10:53:36 +0900
Message-ID: <CAGa2bXZTfubkyD=nT8fCxzF=P3Y1sPnFgj8nKHDjLB2HiPgFvw@mail.gmail.com>
To: Crypto Compress <cryptocompress@googlemail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1137e9860eb30c04f4733bbc
Subject: Re: [PHP-DEV] Unicode strings?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1137e9860eb30c04f4733bbc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

On Thu, Mar 13, 2014 at 10:22 AM, Crypto Compress <
cryptocompress@googlemail.com> wrote:

> Am 13.03.2014 01:01, schrieb Rasmus Lerdorf:
>
>  On 3/12/14, 5:20 AM, Lester Caine wrote:
>>
>>> Crypto Compress wrote:
>>>
>>>> Unicode variable names ARE secondary, but if the handling of unicode
>>>>> works as
>>>>> well as it seems to be for me then it may be an option that can be
>>>>> considered.
>>>>>
>>>> http://3v4l.org/kWb0U
>>>> Please help me, what is this about?
>>>>
>>> Exactly what has already been discussed?
>>> You can use unicode strings in many areas of PHP, but it is not by
>>> design, but rather as the result of 'holes' in the design.
>>>
>> That's not a hole in the design. It was quite deliberate and it had
>> little to do with Unicode at the time. It was a deliberate effort to not
>> artificially limit identifiers beyond that which the language syntax
>> naturally prevented. Think <space> ; , { } ( ) etc.
>>
>> -Rasmus
>>
>
> IMHO it was the right decision to no artificially limit identifiers and i=
t
> is a fair trade-off for case-insensitivity without unicode (class =C3=9F{=
} class
> SS{}).
> With unicode identifiers there is at least one more problem through
> normalization to consider. somewhat simplified: $=E2=98=80=E2=98=81 and  =
$=E2=9B=85 (=3D=3D=3D in unicode)
>

Good point, but users should use NFC UTF-8 without BOM for
variable/function names.
It would be documentation issue.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1137e9860eb30c04f4733bbc--