Re: [Discussion] Last chance for case-sensitive engine

From: 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

« previous php.internals (#83753) next »