# PHP and case-sensitivity inconsistency in PHP 6 - Thread: https://externals.io/message/71592 - Original archive: https://news-web.php.net/php.internals/71592 - Started by Andrea Faulds on 2014-01-26T19:07:59+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #71592 — Andrea Faulds — 2014-01-26T19:07:59+00:00 URL: https://externals.io/message/71592#71592 Good evening all, With the recent discussions making it likely we'll start thinking about things to add, and more importantly, break in PHP 6, I'd like to bring up the topic of case-sensitivity in PHP again. Would it be possible for us to finally be consistent in PHP 6, with everything being case-sensitive (or case-insensitive, as the case may be)? It would be a quite major backwards-compatibility break, but it would also be one that an automated tool could easily fix your code for. Perhaps something like Python's 2to3. Thoughts? -- Andrea Faulds http://ajf.me/ --- ## #71593 — Lester Caine — 2014-01-26T19:26:22+00:00 URL: https://externals.io/message/71592#71593 · In reply to: #71592 Andrea Faulds wrote: > Good evening all, > > With the recent discussions making it likely we'll start thinking about things > to add, and more importantly, break in PHP 6, I'd like to bring up the topic of > case-sensitivity in PHP again. > > Would it be possible for us to finally be consistent in PHP 6, with everything > being case-sensitive (or case-insensitive, as the case may be)? It would be a > quite major backwards-compatibility break, but it would also be one that an > automated tool could easily fix your code for. Perhaps something like Python's > 2to3. > > Thoughts? Personally I do take great care to be consistent in my use of 'case' mainly because of problems when switching between Linux and Windows. Early on I kept hitting problems with libraries that worked fine on Windows, but failed on Linux because someone had been lax on file names! I'm still hitting that problem even today. Therefore I would be more than happy to see the general adoption of case-sensitive naming! -- 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 --- ## #71594 — Kristopher — 2014-01-26T19:32:43+00:00 URL: https://externals.io/message/71592#71594 · In reply to: #71592 I think having a case sensitive nature would be very helpful to the language, especially in terms of portability in the age of autoloaders and translating class names to directory paths. I'm all for this. > Good evening all, > > With the recent discussions making it likely we'll start thinking about > things to add, and more importantly, break in PHP 6, I'd like to bring up > the topic of case-sensitivity in PHP again. > > Would it be possible for us to finally be consistent in PHP 6, with > everything being case-sensitive (or case-insensitive, as the case may be)? > It would be a quite major backwards-compatibility break, but it would also > be one that an automated tool could easily fix your code for. Perhaps > something like Python's 2to3. > > Thoughts? > -- > Andrea Faulds > http://ajf.me/ --- ## #71612 — Chris Wright — 2014-01-26T22:52:05+00:00 URL: https://externals.io/message/71592#71612 · In reply to: #71592 I'm all for casing consistency. I'm very much *against* all-out case sensitivity. I don't want it to be possible to define a function foo and a function Foo that do different things. So essentially, I would like to see case sensitivity at call time (called name must match declaration), but case insensitivity at declaration time (when checking whether a symbol has already been declared): // no change function foo() {} function Foo() {} // error, cannot redeclare function foo // new behaviour foo(); // works Foo(); // error, called name inconsistent with declared name Thanks, Chris > Good evening all, > > With the recent discussions making it likely we'll start thinking about > things to add, and more importantly, break in PHP 6, I'd like to bring up > the topic of case-sensitivity in PHP again. > > Would it be possible for us to finally be consistent in PHP 6, with > everything being case-sensitive (or case-insensitive, as the case may be)? > It would be a quite major backwards-compatibility break, but it would also > be one that an automated tool could easily fix your code for. Perhaps > something like Python's 2to3. > > Thoughts? > -- > Andrea Faulds > http://ajf.me/ --- ## #71615 — Stas Malyshev — 2014-01-26T23:36:08+00:00 URL: https://externals.io/message/71592#71615 · In reply to: #71612 Hi! > So essentially, I would like to see case sensitivity at call time > (called name must match declaration), but case insensitivity at > declaration time (when checking whether a symbol has already been > declared): What would function_exists('Foo') return when foo() is defined? If false, then this code: if (!function_exists('Foo')) { function Foo() { ... } } would not work. If true, then this code: if(function_exists('Foo')) { Foo(); } would not work. Both are working fine now and there's no real reason why shouldn't they keep working. Additionally, making the engine case-sensitive would simplify some areas of function/class handling. But making it inconsistently partially case-sensitive would instead complicate it, as we now would have to make additional checks against original name before calling. My opinion is if we go case-sensitive, it must be full case sensitivity, no exceptions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #71616 — Chris Wright — 2014-01-26T23:57:00+00:00 URL: https://externals.io/message/71592#71616 > Why's that silly? The uppercase form of ß is SS. PHP isn't case-insensitive > at the moment, merely case-insensitive for ASCII only. > This alters the issue somewhat - it opens up the unicode can of worms and it's almost completely unresolvable without changing the rules for identifiers fundamentally. At the moment identifiers can be ASCII [a-zA-Z0-9] plus >=0x80, but no case translation is performed outside the bounds of ASCII [a-zA-Z0-9] - if we were to start interpolating case outside these bounds the a) we'd need to pick a standard set of valid code points (presumably unicode?) and we'd need to start doing some (relatively) complex validation of names. > On a different note, your case-sensitive at declare, case-insensitive at use > approach would not work well for consistency. Consider variables, for > example. There is no difference (except for static variables, I suppose) > between declaration and usage when we're dealing with assignments. Hence > we'd have to have two sets of rules: Semi-case-insensitivity for functions, > and case-sensitivity for variables. Yuck. I'd rather pick one system > (preferably case-insensitivity) and use it everywhere. This is true, but essentially what I'm suggesting is that the check is performed at the point where an entry is created in the relevant symbol table - if an operation would end up creating a thing that already exists with a different casing, blow up. This is already what happens for function/class etc declarations, I'm just suggesting extending this to variables. Thanks, Chris --- ## #71617 — Chris Wright — 2014-01-26T23:57:07+00:00 URL: https://externals.io/message/71592#71617 · In reply to: #71615 > What would function_exists('Foo') return when foo() is defined? > > If false, then this code: > > if (!function_exists('Foo')) { > function Foo() { ... } > } > > would not work. If true, then this code: > > if(function_exists('Foo')) { > Foo(); > } This point is both valid and annoying :-P This indeed cannot work. > My opinion is if we go case-sensitive, it must be full case sensitivity, > no exceptions. Given the above, +1 Thanks, Chris --- ## #71634 — Andrey Hristov — 2014-01-27T10:33:25+00:00 URL: https://externals.io/message/71592#71634 · In reply to: #71592 > Good evening all, > > With the recent discussions making it likely we'll start thinking about > things to add, and more importantly, break in PHP 6, I'd like to bring > up the topic of case-sensitivity in PHP again. > > Would it be possible for us to finally be consistent in PHP 6, with > everything being case-sensitive (or case-insensitive, as the case may > be)? It would be a quite major backwards-compatibility break, but it > would also be one that an automated tool could easily fix your code for. > Perhaps something like Python's 2to3. > > Thoughts? not again, please, not again! Andrey --- ## #71635 — Alain Williams — 2014-01-27T11:05:19+00:00 URL: https://externals.io/message/71592#71635 · In reply to: #71615 > Hi! > > > […] > > What would function_exists('Foo') return when foo() is defined? > > If false, then this code: > > if (!function_exists('Foo')) { > function Foo() { ... } > } > > would not work. If true, then this code: > > if(function_exists('Foo')) { > Foo(); > } > > would not work. Both are working fine now and there's no real reason why > shouldn't they keep working. > > Additionally, making the engine case-sensitive would simplify some areas > of function/class handling. But making it inconsistently partially > case-sensitive would instead complicate it, as we now would have to make > additional checks against original name before calling. > > My opinion is if we go case-sensitive, it must be full case sensitivity, > no exceptions. +1 We need to think about: * there are a few special values that are currently case insenitive, eg: NULL, TRUE. I would suggest that they only be recognised in upper case, eg: null would be invalid. This fits with the meme of constant names being in upper case. * transition, there must be a lot of code that has (accidental) case inconsistencies in function/variable/... names. If PHP were not a dynamic language (eg C) then this change would be caught at compile time. In PHP a case inconsistency is only found when the code is executed. Programs can contain blocks of code that are rarely executed - think: rare error recovery. Something that would help with transition is the option to force variables to be declared. If a variable is then used without being declared an error is raised. We currently have the problem as illustrated below: $foo = 'bar'; echo "foo=$f00"; With case insensitivity this problem will become worse. What I propose is something like perl's 'use strict'. This causes a compilation error if a variable is used that has not been defined. This pragma applies only for the compilation module that it is in; ie it does not apply to 'include'd files and so can be done on a module by module basis. The way that I suggest that we do this is by using the existing keyword 'var'. Eg: var $foo = 'bar'; or var $foo; If 'var' is seen in a module, then use of any variables below MUST be for variables that have been declared. OK: that is the general idea, details need working on. Note that the use of 'var' to declare variables is OPTIONAL, only use it if you want to. -- 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 > * there are a few special values that are currently case insenitive, eg: > NULL, TRUE. > I would suggest that they only be recognised in upper case, eg: null > would be > invalid. This fits with the meme of constant names being in upper case. > Why would you want FUNCTION tellMeEverythingIsOk(){ ECHO TRUE; } to work but not function tellMeEverythingIsOk(){ echo true; } ?? true/false/null aren't constants, they're language constructs like 'array' and 'callable' (and arguably 'function') - or at least they're part of the same group (base types) and would expect them to have the same case conventions. I wouldn't think anyone would want to enforce $var = ARRAY( 'foo' ); on the PHP world. If we're enforcing case sensitivity with the true/false/null keywords, I'd expect 'true' to be the primitive type, 'TRUE' to be a constant that someone could define for some dubiously-sensible purpose (like having the value needed to be set in some database), and 'True' to be a class that someone could define for a slightly more sophisticated purpose ($t = new True(); try { $db->set( 'field', $t->getForDatabase() ); } catch { echo "Could not set field to {$t->getHumanReadable()} ). But I don't see any reason to make true/false/null case sensitive (whichever canonical casing you then choose) in the first place. G --- ## #71642 — Alain Williams — 2014-01-27T16:19:07+00:00 URL: https://externals.io/message/71592#71642 · In reply to: #71640 > > > > […] > > Why would you want > > FUNCTION tellMeEverythingIsOk(){ > ECHO TRUE; > } > > to work but not > > function tellMeEverythingIsOk(){ > echo true; > } I am trying to raise the issue. Thanks for joining the discussion. > ?? true/false/null aren't constants, they're language constructs like > 'array' and 'callable' (and arguably 'function') - or at least they're part > of the same group (base types) and would expect them to have the same case > conventions. We want to do what breaks least code - while accepting that some code will become broken. What I see in random code that I come across is: TRUE, true and True. Maybe we should accept those and not things like 'tRue'. > I wouldn't think anyone would want to enforce $var = ARRAY( > 'foo' ); on the PHP world. Agreed, I was not suggesting that. It seems to be conventional that keywords like 'function' should be in lower case, I was not aware that you could put it in upper case (you can, I just tried), but all the documentation suggests that it should be lower case. > If we're enforcing case sensitivity with the true/false/null keywords, I'd > expect 'true' to be the primitive type, 'TRUE' to be a constant that > someone could define for some dubiously-sensible purpose (like having the > value needed to be set in some database), and 'True' to be a class that > someone could define for a slightly more sophisticated purpose ($t = new > True(); try { $db->set( 'field', $t->getForDatabase() ); } catch { echo > "Could not set field to {$t->getHumanReadable()} ). > But I don't see any > reason to make true/false/null case sensitive (whichever canonical casing > you then choose) in the first place. It does make it consistent with the change towards case sensitivity in function names. -- 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 * there are a few special values that are currently case insenitive, eg: NULL, TRUE. > I would suggest that they only be recognised in upper case, eg: null would be > invalid. This fits with the meme of constant names being in upper case. I'd prefer lowercase, myself, but I do think we need consistency in case for language keywords as well as identifiers. Perhaps having everything lowercase. > * transition, there must be a lot of code that has (accidental) case > inconsistencies in function/variable/... names. If PHP were not a dynamic > language (eg C) then this change would be caught at compile time. In PHP a case > inconsistency is only found when the code is executed. Programs can contain > blocks of code that are rarely executed - think: rare error recovery. > > Something that would help with transition is the option to force variables to > be declared. If a variable is then used without being declared an error is raised. > > We currently have the problem as illustrated below: > > $foo = 'bar'; > echo "foo=$f00"; > > With case insensitivity this problem will become worse. > > What I propose is something like perl's 'use strict'. This causes a compilation > error if a variable is used that has not been defined. This pragma applies only > for the compilation module that it is in; ie it does not apply to 'include'd > files and so can be done on a module by module basis. > > The way that I suggest that we do this is by using the existing keyword 'var'. Eg: > > var $foo = 'bar'; > or > var $foo; > > If 'var' is seen in a module, then use of any variables below MUST be for > variables that have been declared. > > OK: that is the general idea, details need working on. > > > Note that the use of 'var' to declare variables is OPTIONAL, only use it if you > want to. > I somewhat like this idea, it reminds me of ECMAScript 5's "use strict", which I find an invaluable debugging aid and use for all my JavaScript programs. Being able to have a *strictly* optional feature defined in source, not in the INI, would be wonderful. People who want a notice can have it, but myself, I'd like my program to terminate with an error message when I use a variable I haven't defined yet, if it's a strict mode source file. Adding a strict mode would allow us to change other things without breaking BC, too, though I'm not sure what at present. -- Andrea Faulds http://ajf.me/ --- ## #71653 — Yasuo Ohgaki — 2014-01-28T00:45:53+00:00 URL: https://externals.io/message/71592#71653 · In reply to: #71615 Hi all, On Mon, Jan 27, 2014 at 8:36 AM, Stas Malyshev wrote: > > […] > > What would function_exists('Foo') return when foo() is defined? > > If false, then this code: > > if (!function_exists('Foo')) { > function Foo() { ... } > } > > would not work. If true, then this code: > > if(function_exists('Foo')) { > Foo(); > } > > would not work. Both are working fine now and there's no real reason why > shouldn't they keep working. > > Additionally, making the engine case-sensitive would simplify some areas > of function/class handling. But making it inconsistently partially > case-sensitive would instead complicate it, as we now would have to make > additional checks against original name before calling. > > My opinion is if we go case-sensitive, it must be full case sensitivity, > no exceptions. +1 for full case sensitivity, no exceptions. We may provide compatibility check and conversion scripts using tokenizer module. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net