Hi Alexander, On Tue, Feb 24, 2015 at 4:48 PM, Alexander Lisachenko < lisachenko...@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. PHP7 - introduce case sensitivity switch off by default PHP8 - make case sensitivity switch on by default PHP9 - remove case sensitivity switch Case sensitivity is not mandatory. It would be better to choose long term approach. There will be enough time for users to adopt case sensitive names. In mean time, we have no BC in PHP7. It's good for PHP7. IMHO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net