Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79881
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH4gyTXFFYZ=-UR2KJ2y3PHzX32zqSbmwNHRqAQrC4CxaA@mail.gmail.com>
References: <000c01d01ca0$7e70c850$7b5258f0$@yahoo.fr>
	<CAH-PCH4gyTXFFYZ=-UR2KJ2y3PHzX32zqSbmwNHRqAQrC4CxaA@mail.gmail.com>
Date: Tue, 23 Dec 2014 08:47:33 +0100
Message-ID: <CAEZPtU6HhhNip_OYFAhc2LDvbZ_DZaZHTzoNTgTCR=qQbNRm+w@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: "nf.laupretre@yahoo.fr" <nf.laupretre@yahoo.fr>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
From: pierre.php@gmail.com (Pierre Joye)

On Tue, Dec 23, 2014 at 2:17 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre <nf.laupretre@yahoo.fr>
> wrote:
>
>> Hi,
>>
>>
>>
>> I don't know if this was discussed before. So, tell me what you think
>> before
>> I write an RFC.
>>
>>
>>
>> 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 think that the cost of that BC break is too high, and will only happen in
> an alternative implementation (if at all).
> Putting that aside, if we want to go down that road, we should first
> discourage people from such usage, and as we never did that(no E_STRICT no
> E_DEPRECATED) it would be extremely rude to remove support for that in 7.0.
> I think that a Pull Request for adding E_STRICT or maybe even E_DEPRECATED
> would have a chance of getting voted in but depends on the implementation
> and how much overhead would it cost.

I cannot agree on even adding a flag here. There is no gain, the code
base won't change but the cost of the notice/deprecation will be too
high as well, relatively speaking.

CS can be used and enforced on a per project basis if a project wants
to rely on the same cases for his application, libs or modules.
Platforms with case insensitive file systems will work just fine.

Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC. 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?
These are all things we should take into account, not only "heh, let
make symbols case sensitive".

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org