On 24/02/15 08:02, Pavel Kouřil wrote: >> I want to ask this question one more time before PHP7 feature freeze: can >> > we the engine case sensitive from PHP>=7.0? >> > >> > 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 >> > >> > Thoughts? > Hello, > > I'd personally LOVE PHP being case-sensitive, but I think it's not possible. > > Sure, frameworks and newer code will won't be broken, but what about > the tons of "legacy" code? Personally, I saw too much code (and even > examples in tutorials!) using stuff like MySQL_Query(). And case > sensitivity would break this code without a doubt. (I know mysql ext > is deprecated, but that's relevant right now, this is just one of many > examples - the most common one I can think of, actually). > > On the other hand, this could be fixed by running some migration > scripts over code base, so maybe it's not THAT bad? Who knows.
It is fun that some areas are already case sensitive, such as the returns from a database which under the SQL standard defaults to upper case while the convention in code tends to be lower case. One has to convert result arrays case often when trying to work cross platform. However I think that the situation with regards Unicode seems to have been lost in the current battlefield? That a string value needs to be handled with mbstring is another little problem which requires care when pushing strings around. Introducing case-sensitive E_STRICT now would allow an eventual incorporation of proper multilingual support later. Keeping some areas 'English only' does not bother me, but the rest of the infrastructure has already moved on so it is about time PHP joined modern practice? One of the areas that many people may already have worked through is moving from case-insensitive file names in Windows to case-sensitive ones on other platforms which are now a lot more prevalent, so some of the 'BC' problems are outside our control anyway. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
