Re: [Discussion] Last chance for case-sensitive engine
| From: | Derick Rethans | Date: | Wed, 25 Feb 2015 09:40:28 +0000 |
| Subject: | Re: [Discussion] Last chance for case-sensitive engine | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83753@lists.php.net to get a copy of this message | ||
On Tue, 24 Feb 2015, Yasuo Ohgaki wrote:
> On Tue, Feb 24, 2015 at 4:48 PM, Alexander Lisachenko <
> lisachenko.it@gmail.com> wrote:
>
> > There is a draft for that:
> > https://wiki.php.net/rfc/case-sensitivity
> > (mostly empty), so I decided to ask this question in the internals
> > mail list.
> >
> > Pros: more simple O(1) hash table checks for properties, functions,
> > methods, classes without strtolower normalization on the
> > engine/parser level. Consistency with unicode class names (yes, they
> > are case sensitive, check http://3v4l.org/ia0pc),
> > consistency with
> > exisiting PSR0,4 standards (case sensitive mapping of class names to
> > the file names)
> >
> > From my experience, all modern PHP framework don't use
> > case-insensitive code, so chance to break anything for them is
> > really low.
> >
> > Cons: on the extension level things aren't so good and can be some
> > BC breaks (like with phpng)
> >
> > Possible ways:
> >
> > 1) Keep PHP engine case-insensitive for PHP7
> > 2) Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
> > in the extensions (this breaks can be easily fixed)
> > 3) Add a compile-time switch, eg. --with-case-sensitivity to the
> > configuration to have an ability to build PHP with sensitivity and make
> > this option enabled by default since next major version (PHP>=8.0). Add
> > deprecation notices in 7.x
> >
>
> INI switch is better. Compiler switch would not work well, since user
> cannot check their code easily.
An INI setting that changes how syntax or code works is never *never* a
good idea. It's something that many developers have no control over.
To be really honest, I don't think all of the pro's hold up. For a hash
check, there is no change really - the only change that is to remove the
zend_tolower. Previous discussions have IIRC shown that the performance
benefit is minimal. Compatibility with PSR's is also a moot point, as
there are just recommendations.
However, there are a few extra cons: You are going to break
people's code on a large scale. I simply don't think it is worth it
(again, just like when this discussion popped up every year or so for
the last decade).
cheers,
Derick