Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79937
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20141225100514.GK11370@phcomp.co.uk>
References: <000c01d01ca0$7e70c850$7b5258f0$@yahoo.fr>
	<CAH-PCH4gyTXFFYZ=-UR2KJ2y3PHzX32zqSbmwNHRqAQrC4CxaA@mail.gmail.com>
	<CAEZPtU6HhhNip_OYFAhc2LDvbZ_DZaZHTzoNTgTCR=qQbNRm+w@mail.gmail.com>
	<000d01d01ec2$46f2f280$d4d8d780$@yahoo.fr>
	<009a01d01ff4$7d145470$773cfd50$@tekwire.net>
	<20141225100514.GK11370@phcomp.co.uk>
Date: Thu, 25 Dec 2014 21:53:11 +1100
Message-ID: <CAEZPtU5FQkM6rsgBLUUYBoq6gT_-pUTpiNFzSZdKdOf5gYJskw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Dec 25, 2014 at 9:05 PM, Alain Williams <addw@phcomp.co.uk> wrote:
> On Thu, Dec 25, 2014 at 04:40:09AM +0100, Fran=C3=A7ois Laupretre wrote:
>
>> > He will also have to deal with
>> > file ops while being at it. Should they remain case insensitive? Do
>> > manual checks to match the path actually being requested (ie. possible
>> > on windows using meta info), or keep everything the way it is now?
>>
>> Do you mean simulating case-sensitive paths on case-insensitive file sys=
tems ? Why not, depending on the overhead it brings. Unfortunately, I don't=
 have the Windows skills required to work on the subject.
>>
>> About the overhead the check introduces, note that it is supposed to be =
temporary. The final goal is to store symbols as-Is, eliminating the need f=
or lowercase conversions. This would remove a lot of allocations and calls =
to zend_str_tolower_copy(). This would also remove a lot of code.
>
> I see case (in)sensetivity in names of functions/classes/...  as being se=
parate
> from case sensetivity in file names.  There is already a problem for thos=
e who
> develop on MS-Windows/Mac and deploy on *nix - a typeo can lead to a fail=
ure at
> run time.  The fix is simple, people do not complain that PHP should prot=
ect
> them from this.
>
> I am a believer in simplicity, which is part of the reason that I support=
 the
> idea of removing the complexity of case insensitivity in function/... nam=
es.
>
> Case folding has a slight speed penalty and does not work properly. It do=
es not
> fold unicode characters outside the range U+40 - U+7A (ie US ASCII), so b=
est to
> just forget it.

I do not see a reason why some code having ran out of the box for more
than a decade should be changed for 7 for purely syntax sugars reason,
like ImageCreate to imagecreate or the likes. It just does not make
sense to me. Ignoring the paths issue, related to classes, autoload,
etc. also sounds very weird to me.

Anyway, let get a RFC ready, a patch that does not break anything
(well, except the case issue :) ), almost everything about this topic
else has been said already.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org