Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6HhhNip_OYFAhc2LDvbZ_DZaZHTzoNTgTCR=qQbNRm+w@mail.gmail.com>
References: <000c01d01ca0$7e70c850$7b5258f0$@yahoo.fr>
	<CAH-PCH4gyTXFFYZ=-UR2KJ2y3PHzX32zqSbmwNHRqAQrC4CxaA@mail.gmail.com>
	<CAEZPtU6HhhNip_OYFAhc2LDvbZ_DZaZHTzoNTgTCR=qQbNRm+w@mail.gmail.com>
Date: Tue, 23 Dec 2014 09:00:06 +0100
Message-ID: <CAEra97r4HGrMkdVCzo-iAme6JSmn8fZfMEc-n28a=BzXnoNvkQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, "nf.laupretre@yahoo.fr" <nf.laupretre@yahoo.fr>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb03bda3530ad050add905f
Subject: Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
From: nek.dev@gmail.com (Maxime Veber)

--047d7bb03bda3530ad050add905f
Content-Type: text/plain; charset=UTF-8

Even if i'm a php developer since a while, i never new or see usage of the
case-insensitive "feature". IMO that's something a bit terrible and people
do not use it but *make mistakes* that PHP "automatically fix". This
behavior is very weird and comes with bad code quality.

Of course this is a BCBreak, but as Yasuo Ohgaki said, this bc break is not
so hard to detect. Please consider adding the warning in PHP 5.7 and fixing
it in PHP 7.

Thanks for reading.

Cheers,

2014-12-23 8:47 GMT+01:00 Pierre Joye <pierre.php@gmail.com>:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7bb03bda3530ad050add905f--