[LawnGnome]

Unfortunately, the obvious answer (parse code in the C locale) breaks code that's in the wild and relies on PHP's undocumented locale-specific case-insensitivity.

Obviously, case-insensitive identifiers are a bad idea, but PHP is stuck with them at this point.

[Tloewald]

I don't think it's "obvious" at all. The problems caused by case sensitive identifiers are legion, especially in dynamic languages with implicit declaration. It's not at all clear to me that this problem is of case insensitive identifiers and not simply in PHP's implementation.

[Udo]

Changing the case insensitivity of PHP identifiers is a good idea. I suspect breakage would be minimal and easily fixable. One has to keep in mind that variable names are already case sensitive in PHP, and most (reasonably good) code I've seen in the wild does honor the spelling of class and method names.

Of course it will never happen, but I really think this would be a great idea for the next major version. Backwards compatibility is important but not at all costs. A language needs to remain agile enough to allow for the recognition of (and ultimately the fixing of) mistakes.

[Xylakant]

I doubt that breakage would be minimal. I'm not as certain as you that most code does honor the spelling of class and method names, but even if we assume that this is the case I'd assume that there are tons of undetected errors. Currently, there's just no way to test that you're using the proper spelling, so nobody does.

[Udo]

It would be trivial to write a command line tool to check (and maybe automatically fix) those typos. Incorporating it into a major new version also ensures everybody has enough time to prepare - and in case of hopeless and unfixable legacy apps: there is always the option not to upgrade.

Breaking changes in programming languages are not that uncommon, C# and Perl spring to mind from personal experience, but also to a lesser degree such things have happened with PHP itself (and it became better for it). In this case, it's actually a change that moves the runtime's behavior closer to what's expected. It's a change that improves internal consistency while also eliminating silly bugs like the one discussed here.

[Xylakant]

I'm not against changing that behavior since it's arguably stupid and inconsistent [1], but I'm wary of "trivial" changes. It's not only apps that need fixing, pretty much every library needs checking (and maybe fixing). This cannot be done with a commandline check, since classnames can be constructed on the fly, called via eval() or call_user_func() etc. Class names may be loaded or even defined on the fly (the SOAP Pear Extension does this to create proxies). All those cases can only be checked by executing the program. It's probably a good change, but this is anything but trivial.

[1] actually, I don't care at all since I moved on to greener pastures.

[acdha]

Having seen the hairballs of creative PHP in the wild, I'd think the only sane way to do this would be some sort of deprecation warning whenever a symbol lookup matched only case insensitively.

[Xylakant]

Like the ones that they introduced to fix array[key_without_quotes] where key_without_quotes was mapped to a string if it was not a defined constant and a NOTICE was issued? The first thing everyone did was turn off E_NOTICE since practically all code emitted that notice. It took years until you could run apps with E_NOTICE turned on :)

[acdha]

True: I spent years swimming upstream trying to get PHP developers to log sensibly and actually fix problems rather than suppressing the notices, which is probably why I'm much happier with the Python community.