I think this was a good explanation:<p>"No, the problem results because lowercase i (in most languages) and uppercase I
(in most languages) are not actually considered to be the upper/lower variant of
the same letter in Turkish. In Turkish, the undotted ı is the lowercase of I,
and the dotted İ is the uppercase of i. If you have a class named Image, it
will break if the locale is changed to turkish because class_exists() function
uses zend_str_tolower(), and changes the case on all classes, because they are
supposed to be case insensitive. Someone else above explained it very well:<p>"class_exists() function uses zend_str_tolower(). zend_str_tolower() uses
zend_tolower(). zend_tolower() uses _tolower_l() on Windows and tolower() on
other oses. _tolower_l() is not locale aware. tolower() is LC_CTYPE aware."<p>Edit: Someone else later said the following (I'm wondering if it's true):<p>"This, practically, can't be fixed. Mainly because there's no way to know if 'I' is uppercase of 'i' or 'ı' since there's not a separate place for Turkish 'I' in code tables. The same holds for 'i' (can't be known if it's lowercase of 'I' or 'İ').
I told 2 years ago and will say it again: PHP should provide a way to turn off case-insensitive function/class name lookup. No good programmer uses this Basic language feature since identifiers are case-sensitive in all real languages like Python, Ruby, C#, Java."
If there are so many people depending on PHP and all the code written in PHP in all of Turkey, why doesnt someone in Turkey fix the problem?<p>Or anywhere for that matter?<p>There is no "they" in this equation. There is no person who should be held more accountable than you or I for fixing this problem.<p>The choices are simple:<p>1) Fix the problem<p>2) Find a work around<p>3) Don't use PHP<p>What's that? There is a lot of open source software that you wanted to use for free that's written in PHP that does just what you need except for this tiny little trivial thing that should be easy to fix? Well too bad!<p>Trade off the cost of fixing it against the cost of rewriting the big, free, open source package that's written in PHP you wanted to use, in the programming language of your choice, and stop complaining.
This is a huge bug. Believe or not, many dev people in Turkey use locale tr_TR (which is perfectly normal) and when they begin to use "any" off-the-shelf PHP library/class with uppercase-I, it does not work at all. A little example, if APC has a class with I, it won't work on your tr_TR configured Windows Server.<p>PHP is crap. Not even classical ASP had such bugs and it was perfectly passing the Turkey test (<a href="http://www.codinghorror.com/blog/2008/03/whats-wrong-with-turkey.html" rel="nofollow">http://www.codinghorror.com/blog/2008/03/whats-wrong-with-tu...</a>) and Unicode supporting languages didn't have such a bug. E.g. Java, Python.<p>PHP is crap. This bug is clearly a WONTFIX, it's been 10 years since it is reported. I remember this bug when I was 14, thank God I moved on to other languages afterwards.
Every time an article critical of PHP appears, defenders come out of the woodwork. It's a great language, they say. It's no more flawed than any other language. Critics are just biased. It has problems, but other languages have problems too. People build large apps with PHP, so it must be good.<p>But come on. This language is complete crap. Code spontaneously fails depending on the locale? And the bug has been open for <i>ten years</i> and still is not fixed? And this is only one bizarre and inexplicable bug out of hundreds, maybe thousands, of bizarre and inexplicable bugs in PHP.<p>This language isn't defensible. If you want to say that it's worth dealing with the flaws due to the ecosystem, fine, fair enough. But don't tell us that PHP is no worse than any other language. It's <i>far</i> worse.
It's kind of hard <i>not</i> to bash PHP for crap like this.<p>Yes, the PHP ecosystem is friendly, easy, cheap, etc. etc.<p>But as a programming language <i>per se</i>... Come on, PHP.
PHP is a big legacy open source project, worked on by many volunteers whenever they can spare the time, just like any other open source project.<p>It is wildly successful despite this and many other bugs.<p>I only wish that the people who spend as much time attacking PHP and it's developers endlessly would instead focus some of that energy into helping to improve PHP, but I guess some of us are just negatively charged.<p>Sad that we have yet another anti-PHP posting hitting the front of HN in as many days, let the hating re-commence (again)...
That's why, for example, .NET world has .ToLowerInvariant() and .ToUpperInvariant() and developers are advised to use it when doing internal stuff. Interpreting / parsing a language is clearly an internal task and shouldn't be affected by locale changes.
It's also referred as The Turkey Test :
<a href="http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html" rel="nofollow">http://www.moserware.com/2008/02/does-your-code-pass-turkey-...</a><p><a href="http://www.codinghorror.com/blog/2008/03/whats-wrong-with-turkey.html" rel="nofollow">http://www.codinghorror.com/blog/2008/03/whats-wrong-with-tu...</a>
What was the advantage of case insensitive class and function names? Sounds to me like someone that was implementing very early on without great reasons and them kept for backwards comparability. In all my programming in PHP I have never thought to take advantage of this.
I don't understand what's the problem with fixing this really. I would completely agree that making "Info" and "info" class names compatible is "not fixable", but what is the problem in making "Info" work if both the definition and usage are the same case? The bug says that this is exactly backwards - mixed case works, but same case doesn't.<p>The only way to make it not work is to first change the case in one locale and then case-insensitive compare it in another locale. Why would this kind of operation ever happen? Any sane situation should "just work":<p>- in declaration convert to lower-case and save, in usage convert to lower-case and lookup -> has to work<p>- in declaration save original, in usage search all classes with case-insensitive compare -> has to work<p>How was that bug ever created in the first place? I get the fact that "I" doesn't match to lower-case "i" in tr_TR, but why does it matter when comparing strings which should be equal? Just be consistent in how both the declarations and usages are converted...
It is likely no one who regularly commits to PHP is effected by this issue and it requires non trivial changes to the way PHP works to fix.<p>Granted given the usual pragmatism of PHP someone should have just hacked something in by now.
This is my biggest problem with PHP. Aside from poor language construction , and the plethora of poorly written code the core language has lots of problems in it. When upgrading to PHP 5.4.3 I found six or seven show stopper bugs in PHP and some of its extensions ( one of which has never worked ). I am still waiting on the fix to one of them. <a href="https://bugs.php.net/bug.php?id=62302" rel="nofollow">https://bugs.php.net/bug.php?id=62302</a>
Please stop telling PHP is a crap. News on the topic are damn to high. Think that PHP coders are beginning to migrate to stuff like python and that most of them don't want to learn programming, they still want to monkey write program and that through trial and errors it works. I am on a one of the #python-xx irc channel, it is an horror.<p>PHP is cool, it is useful, it is a magnet for bad developers. This way they don't pollute our ecosystems.
PHP is to Ruby(Or whatever your hater flavor is) as Christians is to Muslims. Neither of them are going to go away until one of them kills all the others. The more likely alternative is something else coming and destroying them both.