On Sun, Sep 24, 2017 at 11:52:49AM +0100, Lester Caine wrote: > That sums it up nicely Alain ... > Now the question is actually ... do we stay in the dark ages of single > byte character sets or do we move to fully embrace a current well > established and extensively used standard. Unicode has perhaps shirked > on the matter of 'case-insensitive' so there is no clean solution to > that today. That should not prevent the switch to unicode and other > threads such as the csv routines are now highlighting additional 'edge > cases' where unicode needs addressing, or kicking into the long grass of > extensions of mbstring? Maintaining 'case-insensitive' for single byte > character sets is an option, but then one needs to stay with that for > the whole code functionality? Allowing multibyte constant names with the > current limited sub-set of case conversion is just not sensible, but in > the absence of a clean unicode case folding/conversion which is the > sensible next step?
We also need to think about how our decisions here affect how PHP is used; in particular robustness, correctness, ... of code that people write. I believe that one attribute of the mind of a good programmer is precision/exactness - eschewing sloppyness. Thus if a function is written DoSomething() then it should be spelled that way, not doSomething(), etc. Also PHP programmers are likely to write Javascript - which is case sensitive. I have also seen problems where someone has developed code using Microsoft SQL, they are then asked to port it to a case sensitive database, eg MySQL**. Or an application written on a case insensitive file system (Eg MS Windows) and then try to deploy it on Linux: only to have includes & fopens fail because they have been inconsistent in how they wrote file names. [[ I do not want to get into a discussion about the rights/wrongs of case (in)sensitive file names - we must just accept that as part of the world that we live in. ]] So encouraging the ''names are case sensitive'' meme is, IMHO, good. Then look at the internals of the PHP engine. Case insensitively adds complexity (== places for bugs to lurk) and makes it slower - name lookup happens a lot, it is not just a once off (& off line) compilation process. Some of us work hard to make the PHP engine 0.5% faster - so why make it slower with something that we can easily avoid ? Yes: case insensitivity is nice, I have that option set in my program editor search; but I am a programmer; to use PHP I have to put in a lot of effort to learn how to do things -- the same is true for any programming language. We are not talking about real end users such as my mother $$ - people who we try to make our systems usable for without having to train them. You ask what to do ? I suggest that case insensitiveness in single byte character sets (constant & function names) should be depricated, but enabled for one major release with an init flag -- just as was done for register_globals. That would give everyone a couple of years to tidy their code up. Then kill case insensitve anything in PHP [[ other than the likes of strcasecmp() ]]. **OK: MySQL has a switch to make table names, etc, case insensitive - but enabling that means a lot of testing to ensure that nothing else breaks. $$ I don't want to be rude about her, so maybe I ought to use a different group of clueless people, politicians perhaps ? :-) -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
