Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79827
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <000c01d01ca0$7e70c850$7b5258f0$@yahoo.fr>
Date: Sat, 20 Dec 2014 22:45:39 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <EE790D15-E5B9-4556-AB9A-EEF17FC45503@ajf.me>
References: <000c01d01ca0$7e70c850$7b5258f0$@yahoo.fr>
To: nf.laupretre@yahoo.fr
Subject: Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
From: ajf@ajf.me (Andrea Faulds)

Hey Fran=C3=A7ois, (I assume there=E2=80=99s a =C3=A7, I apologise if =
not)

> On 20 Dec 2014, at 22:01, F & N Laupretre <nf.laupretre@yahoo.fr> =
wrote:
>=20
> I don't know if this was discussed before. So, tell me what you think =
before
> I write an RFC.

Ah, this subject has come up before, I think. :)

> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are already case-sensitive). Actually, I =
never
> understood why they are case-insensitive. Even if the performance gain =
is
> negligible, I think it could be the right time to question this.

I=E2=80=99d thought of doing this before, but the =
backwards-compatibility cost is too high.

I would like to see more case uniformity, but I think this is the less =
practical direction. Instead of making everything case-sensitive, we =
should make everything case-insensitive, which would break far less =
stuff, and is a smaller change. That=E2=80=99d mean constants, variable =
names and properties would need changing, everything else is already =
case-insensitive.=20

I don=E2=80=99t think making constants and variable names =
case-insensitive would cause a problem. I reckon it=E2=80=99s unlikely =
that someone has two constants differing only by case, ditto for =
variable names, and both live in their own namespaces so this wouldn=E2=80=
=99t create conflicts. Even if someone does, this is probably quite a =
rare occurrence and could be easily fixed.

The problematic case is properties, because although PHP code probably =
doesn=E2=80=99t rely on them being case-sensitive most of the time, =
lacking preservation of case for serialised properties would be quite a =
problem. For example, an object serialised to JSON and then decoded =
might, with the right flags passed, be unserialised as an array. Array =
keys are case-sensitive in PHP (as they should be, I don=E2=80=99t want =
to change that), so now a lookup that worked before might not now =
because the case wasn=E2=80=99t preserved. Even if we took care to =
preserve case, there=E2=80=99s also the problem of objects used as =
associative arrays, which we explicitly encourage with ArrayObject. =
Plus, JSON objects decode to PHP objects by default, so objects used as =
case-sensitive dictionaries in incoming JSON would break. For these =
reasons, I don=E2=80=99t think we should touch properties.

In summary, case-sensitivity everywhere would be a massive BC break, but =
case-insensitivity for everything except properties might be doable.

Thanks for writing! :)
--
Andrea Faulds
http://ajf.me/