6 ms·

PHP Bug #18556 : Setting locale to 'tr_TR' lowercases class names

92 points by pixdamix 14y ago

kitsune_ 14y ago
Words fail me.
- lollancf37 14y ago
  In a way, that is amazing. Truly.
- ebiester 14y ago
  It's funny, the first thing I thought is "someone was having trouble with the turkish I and tried a hackaround, and now it's unfixable." I blame Atatürk. If I had a time machine, I'd skip killing Hitler and travel back to the language reform time. "Do you know how much trouble this is going to cause us? Reuse the X, make one a dotted e. I don't care, this is going to fuck everything up!"
  - gokhan 14y ago
    Take the case of software insisting on state input hence unusable outside US. Do you blame the error to George Washington?
    - ebiester 14y ago
      Şimdi İstanbul'da oturuyorum. :) (I think that's right, I'm still learning the language...) The comment was meant to be snarky -- obviously, the e-i-ö-ü \ a-ı-o-u rule would be broken, which is the reason for the undotted I. Further, nobody could have anticipated in 1927 the vast extent of automation that we are going through now. For those that don't know Turkish, there is a faced of the language called vowel harmony. When suffixes are added to a word, which is common in Turkish for everything from pluralization, verb congugations to prepositions, the vowels in the suffix will be altered to match the last vowel. (Some Arab loanwords don't follow this, mind you, but it works 98% of the time.) So, the dotted and undotted vowels (except e for some reason) all follow this pattern. (Incidentally, however, the problems could be solved by turning the single dotted i into a double dotted I, keeping the original symmetry. At that point, a lowercase dotted I would no longer break any system, since you could map them to be functionally equivalent for anything after the reform. While we're at it, I have a few ideas for English language reform...)
      - devmach 14y ago
        You are missing the point that "new" alphabet was way more before designed than "systems". Right way should be involving in a process of developing standards, not changing some chars because some new tech come and has problems with the language ( going rampage as you mentioned earlier isn't also a valid solution ).
        ebiester 14y ago
        I don't quite understand your point here. I understand which came first, by quite some time. It happens that this is a stickier problem than merely "developing standards." What happens when an American tries to log in from a Turkish terminal? If everything is made case insensitive, i turns into İ rather than I. Similarly, what happens when a Türk logs in from another terminal? Do you have the locale attached to the user? (Public terminals can be an issue if someone can't change the keyboard layout. Do they log in as denIz? Does that work? It might if everything is brought to upper case, but not lowercase. The Turkish I is one of the most interesting issues in internationalization.
  - ibotty 14y ago
    "I'd skip killing Hitler" would still be a bad idea. you cannot compare the shoa to language reform.
    - ebiester 14y ago
      http://www.abyssapexzine.com/wikihistory/ http://www.abyssapexzine.com/wikihistory/ is the reference. I assumed a common geek humor touchpoint. "...everybody kills Hitler on their first trip. I did. It always gets fixed within a few minutes, what’s the harm?"
- dasil003 14y ago
  I know it seems insane, but Turkish capitalization is not fun to work with as a programmer. When they latinized the alphabet 100 years ago or so, they were short on vowels and so it must have seemed pretty clever and convenient to make i and I separate letters with İ and ı respective case pairs. From a western programmers perspective though it's one of the worst unicode special cases owing to its combined unexpectedness and commonness. Just as an example, text-transform: uppercase has been broken in Turkish for all major browsers until I believe Firefox finally fixed it late last year, after having a bug open for nearly a decade.
  - obilgic 14y ago
    Just my curiosity, how do you know that they were short on vowels?
    - deleted 14y ago
      [deleted]
    - mtts 14y ago
      I'm not the parent and I'm not very familiar with this specific case, but in general the number of vowels in the Latin alphabet is really only sufficient for, well, Latin, and for languages that have the same, rather limited, number of vowels or less. English, for example, has more than 20 vowels (according to Wikipedia: http://en.wikipedia.org/wiki/English_phonology http://en.wikipedia.org/wiki/English_phonology), but then English happens to be a language with a larger than average number of vowels. Turkish makes do with a mere 8, but even that is more than the Latin alphabet can accommodate (5)
  - zokier 14y ago
    From my point of view there could be one very simple solution: just add new codepoints in unicode for turkish I and i. So the latin i would follow the common case conventions, and turkish i would use whatever crazy stuff they have there. Of course that might be bit late to do now, there is probably too much text encoded in the current format.
    - 14y ago
- chris_wot 14y ago
  They fail for Turkish PHP developers also. You're in good company!
celalo 14y ago
I is not capital of i in Turkish. Instead, İ is capital of i and I is capital of ı. They are two different letters.
- endtime 14y ago
  And this should affect class names why?
  - batterseapower 14y ago
    Apparently identifier lookup is done case-insensitively...
    - deleted 14y ago
      [deleted]
- Raticide 14y ago
  No other language has this problem. The locale is irrelevant. The class name is just a series of bytes; it shouldn't need to transform the case.
  - Permit 14y ago
    I believe it's because PHP supports case insensitive class names. It sounds like this will not change: https://bugs.php.net/bug.php?id=26575&edit=1 https://bugs.php.net/bug.php?id=26575&edit=1
    - shuzchen 14y ago
      Class and function names are case insensitive. But variables are not. Go figure that one out.
      - RobAley 14y ago
        I'd prefer them both to be one way or the other, but if they have to be different this is the right way to do it. For instance, functions can check to see what name the were called by (and process the call differently if we want to distinguish between cases). Variables can't do that so we must explicitly distinguish between them.
celalo 14y ago
I is not capital of i in Turkish. Instead, İ is capital of i and I is capital of ı. They are two different letters.
yuvadam 14y ago
It's kind of hard not to bash PHP for crap like this. Yes, the PHP ecosystem is friendly, easy, cheap, etc. etc. But as a programming language per se... Come on, PHP.
cocoflunchy 14y ago
I'm looking forward to the tenth birthday of this bug... Only 24 days to go !
robryan 14y ago
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. Granted given the usual pragmatism of PHP someone should have just hacked something in by now.
deleted 14y ago
[deleted]
j_col 14y ago
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. It is wildly successful despite this and many other bugs. 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. Sad that we have yet another anti-PHP posting hitting the front of HN in as many days, let the hating re-commence (again)...
- deleted 14y ago
  [deleted]
- Raticide 14y ago
  I think the people that attack it would rather see it die off than be "improved".
  - davidw 14y ago
    I don't think those people understand the economics of programming languages. It's not going to die off any time soon, what with all the thousands of companies that use it, and zillions of lines of code. As someone who would rather not ever work with PHP again, the best thing is to simply focus on other languages and environments, helping to bolster those ecosystems.
    - lmm 14y ago
      Agreed, but publicising stupid problems with PHP actually does help that cause - it might push someone who's "on the fence" over to using a better system.
      - balac 14y ago
        I'm one of those on the fence. I've spent most of my programming life working on PHP and the recent barrage of negativity against PHP has made me more interested in learning another language, if just to make an educated comparison and see whether I am continue to use PHP "because I know it" or because it is actually good. I'm currently having a go at Python + Flask in my spare time.
Mithrandir 14y ago
I think this was a good explanation: "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: "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." Edit: Someone else later said the following (I'm wondering if it's true): "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."
- simias 14y ago
  But, why should the locale change the way PHP code is interpreted? Shouldn't LC_ALL="C" when parsing the code? Maybe it breaks if you embed unicode strings or something. What do other languages do?
  - shuzchen 14y ago
    If it wasn't clear by the comments on the bug report or by the quoted sections of this comment's parent, let me rephrase it. This issue is entirely caused by the fact that PHP is case insensitive for classes and function names (but not variables, go figure). That is, if you define a class MyClass, you can instantiate it using MyClass or myclass or MYCLASS. You can call the functions from the standard library in whatever case either (so, array_map or ARRAY_MAP is fine). Based on the behavior of this bug, it appears that the way PHP handles this case insensitivity is that it just lowercases all class and function names before resolving them. And this bug in particular shows up for Turkish because 'i' is not the lowercase equivalent of 'I'. Pretty much all other modern languages are case sensitive, so I'd be surprised to find this issue elsewhere.
fmavituna 14y ago
It's also referred as The Turkey Test : http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html http://www.moserware.com/2008/02/does-your-code-pass-turkey-... http://www.codinghorror.com/blog/2008/03/whats-wrong-with-turkey.html http://www.codinghorror.com/blog/2008/03/whats-wrong-with-tu...
gokhan 14y ago
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.
- TazeTSchnitzel 14y ago
  Yep. .NET also has a nice set of string comparison classes for dictionary lookups to avoid exactly this kind of thing.
- Draiken 14y ago
  Unfortunately you can't compare .NET to PHP. Ever.
  - billpg 14y ago
    They just did.
4qbomb 14y ago
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.
- 4qbomb 14y ago
  This is simply proof of the demographic and blind nature of the Hacker News audience. Pathetic
alpb 14y ago
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. PHP is crap. Not even classical ASP had such bugs and it was perfectly passing the Turkey test (http://www.codinghorror.com/blog/2008/03/whats-wrong-with-turkey.html http://www.codinghorror.com/blog/2008/03/whats-wrong-with-tu...) and Unicode supporting languages didn't have such a bug. E.g. Java, Python. 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.
- kalleboo 14y ago
  If this is such a dealbreaker for developers in Turkey, why have none of them, in the 10 years this bug has been alive, submitted a patch for it? PHP is open source, it relies on code submissions. edit: not trolling, just curious. What drives people to complain about specific, well-defined open source bugs without any effort to fix it? I understand hard-to-nail down issues like user experience, but this shouldn't be that hard to plan out and fix independently.
  - josteink 14y ago
    See Mithrandir's comment: http://news.ycombinator.com/item?id=4187943 http://news.ycombinator.com/item?id=4187943
  - slurgfest 14y ago
    If there are viable alternative projects which never had that problem, you can save all the time rather than trying to salvage someone else's broken software. It's a lot less time and trouble. What reason do I even have for fixing your project? I don't owe PHP loyalty when it is broken for me. If there are viable alternative projects which are more responsive to bug reports, that is more promising for the future - if a second bug I see is reasonably likely to be fixed in the future, I can feel more confident basing my own code on it. People spend months and years writing apps on top of things like PHP and once they have the code they don't necessarily have a lot of choice. At that point maybe you fix the bugs in your dependencies rather than rewrite your own app. But when you have a choice, you don't adopt a tool which is going to leave you with this much technical liability. This is offered peacefully in an attempt to explain the question which seems to confuse you.
luminaobscura 14y ago
wow, it has been 10 years and no fix!
robryan 14y ago
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.
- RobAley 14y ago
  I'm assuming the original reason is lost in the mists of time, but one advantage it has when calling/using external/3rd party code is in style conventions. If in my code my convention is to use functionNames but in yours you use functionames or FunctionNames, I can still code in my style after include()ing your file. A small advantage, granted.
- meepmorp 14y ago
  > What was the advantage of case insensitive class and function names? The programmer can be sloppy/lazy and still have thing turn out largely as expected. If you're just learning how to program, this makes it a bit easier, since a whole class of possible problems goes away.
dools 14y ago
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? Or anywhere for that matter? 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. The choices are simple: 1) Fix the problem 2) Find a work around 3) Don't use PHP 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! 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.
- gouranga 14y ago
  You are the only reasonable voice on the matter I've heard so far. Infinite upvotes from me. We all know PHP has its shortcomings, but there appears to be a witch hunt going on here.
  - josteink 14y ago
    We all know PHP has its shortcomings, but there appears to be a witch hunt going on here. I think some of the witch hunt comes in attempt to steer people away from a language which is badly designed and has a million bugs which cannot be fixed without breaking most of the existing code written for the language. Pestering a language like that is only fair. While I'm sure it gets tiresome for those who for whatever reason have to work or prefer working in PHP, it is only a polite gesture to the software-developers who has yet to take that dark path. If they can be dissuaded, they should.
    - gouranga 14y ago
      Granted it's horrible (I agree there), but it does solve a lot of problems rather quickly. I'd argue that it solves the problems in the '00s that Visual Basic did in the 90's. What I'd really like to see is a solution for '10s which fits that niche and is equally as productive, yet less horrible.
ObnoxiousJul 14y ago
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. PHP is cool, it is useful, it is a magnet for bad developers. This way they don't pollute our ecosystems.
jister 14y ago
If this is a known bug and it's been there for 10 years then why the hell did the developer STILL chose to use PHP in the first place?
- Draiken 14y ago
  Unfortunately on legacy systems someone else chose PHP for him a long time ago... Poor developer that has to deal with this stuff. Been there.
viraptor 14y ago
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. 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": - in declaration convert to lower-case and save, in usage convert to lower-case and lookup -> has to work - in declaration save original, in usage search all classes with case-insensitive compare -> has to work 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...
- deleted 14y ago
  [deleted]
dkhenry 14y ago
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. https://bugs.php.net/bug.php?id=62302 https://bugs.php.net/bug.php?id=62302
devgutt 14y ago
Bug is a bug is a bug is a bug
mikeash 14y ago
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. But come on. This language is complete crap. Code spontaneously fails depending on the locale? And the bug has been open for ten years 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. 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 far worse.
- lonnyk 14y ago
  > Code spontaneously fails depending on the locale? It doesn't spontaneously fail. The languages functions are case-insensitive and they documented this. [1] [2] When you change the locale to Turkish the letters change. Thus, the class name changes and no longer works as expected. So it is documented because it may not as expected, but it is not spontaneous. [1] http://www.php.net/manual/en/functions.user-defined.php http://www.php.net/manual/en/functions.user-defined.php [2] https://gist.github.com/3033533 https://gist.github.com/3033533
  - viraptor 14y ago
    That's incorrect. It's not behaving as documented. Whether you compare in a case-sensitive or case-insensitive way "Info" should always match "Info". The bug results in a situation where it doesn't. I'd accept that you cannot reference class "info" using name "Info" in Turkish locale, but that's not the case here.
  - mikeash 14y ago
    Nowhere in your documentation does it state that a class name cannot be accessed using the exact same, byte-for-byte identical name, depending on locale. Case sensitivity changing depending on locale would be weird, but at least vaguely sensible. Identical strings no longer matching is just plain wrong.
- 14y ago
patio11 14y ago
The situation is not helped by the frequent OSS community suggestion: "Just patch Turkish." while mumbling "Bloody non-ASCII ingrates."

92 points by pixdamix 14y ago

kitsune_ 14y ago

Words fail me.

lollancf37 14y ago
In a way, that is amazing. Truly.
ebiester 14y ago
It's funny, the first thing I thought is "someone was having trouble with the turkish I and tried a hackaround, and now it's unfixable." I blame Atatürk. If I had a time machine, I'd skip killing Hitler and travel back to the language reform time. "Do you know how much trouble this is going to cause us? Reuse the X, make one a dotted e. I don't care, this is going to fuck everything up!"
- gokhan 14y ago
  Take the case of software insisting on state input hence unusable outside US. Do you blame the error to George Washington?
  - ebiester 14y ago
    Şimdi İstanbul'da oturuyorum. :) (I think that's right, I'm still learning the language...) The comment was meant to be snarky -- obviously, the e-i-ö-ü \ a-ı-o-u rule would be broken, which is the reason for the undotted I. Further, nobody could have anticipated in 1927 the vast extent of automation that we are going through now. For those that don't know Turkish, there is a faced of the language called vowel harmony. When suffixes are added to a word, which is common in Turkish for everything from pluralization, verb congugations to prepositions, the vowels in the suffix will be altered to match the last vowel. (Some Arab loanwords don't follow this, mind you, but it works 98% of the time.) So, the dotted and undotted vowels (except e for some reason) all follow this pattern. (Incidentally, however, the problems could be solved by turning the single dotted i into a double dotted I, keeping the original symmetry. At that point, a lowercase dotted I would no longer break any system, since you could map them to be functionally equivalent for anything after the reform. While we're at it, I have a few ideas for English language reform...)
    - devmach 14y ago
      You are missing the point that "new" alphabet was way more before designed than "systems". Right way should be involving in a process of developing standards, not changing some chars because some new tech come and has problems with the language ( going rampage as you mentioned earlier isn't also a valid solution ).
      - ebiester 14y ago
        I don't quite understand your point here. I understand which came first, by quite some time. It happens that this is a stickier problem than merely "developing standards." What happens when an American tries to log in from a Turkish terminal? If everything is made case insensitive, i turns into İ rather than I. Similarly, what happens when a Türk logs in from another terminal? Do you have the locale attached to the user? (Public terminals can be an issue if someone can't change the keyboard layout. Do they log in as denIz? Does that work? It might if everything is brought to upper case, but not lowercase. The Turkish I is one of the most interesting issues in internationalization.
- ibotty 14y ago
  "I'd skip killing Hitler" would still be a bad idea. you cannot compare the shoa to language reform.
  - ebiester 14y ago
    http://www.abyssapexzine.com/wikihistory/ http://www.abyssapexzine.com/wikihistory/ is the reference. I assumed a common geek humor touchpoint. "...everybody kills Hitler on their first trip. I did. It always gets fixed within a few minutes, what’s the harm?"
dasil003 14y ago
I know it seems insane, but Turkish capitalization is not fun to work with as a programmer. When they latinized the alphabet 100 years ago or so, they were short on vowels and so it must have seemed pretty clever and convenient to make i and I separate letters with İ and ı respective case pairs. From a western programmers perspective though it's one of the worst unicode special cases owing to its combined unexpectedness and commonness. Just as an example, text-transform: uppercase has been broken in Turkish for all major browsers until I believe Firefox finally fixed it late last year, after having a bug open for nearly a decade.
- obilgic 14y ago
  Just my curiosity, how do you know that they were short on vowels?
  - deleted 14y ago
    [deleted]
  - mtts 14y ago
    I'm not the parent and I'm not very familiar with this specific case, but in general the number of vowels in the Latin alphabet is really only sufficient for, well, Latin, and for languages that have the same, rather limited, number of vowels or less. English, for example, has more than 20 vowels (according to Wikipedia: http://en.wikipedia.org/wiki/English_phonology http://en.wikipedia.org/wiki/English_phonology), but then English happens to be a language with a larger than average number of vowels. Turkish makes do with a mere 8, but even that is more than the Latin alphabet can accommodate (5)
- zokier 14y ago
  From my point of view there could be one very simple solution: just add new codepoints in unicode for turkish I and i. So the latin i would follow the common case conventions, and turkish i would use whatever crazy stuff they have there. Of course that might be bit late to do now, there is probably too much text encoded in the current format.
  - 14y ago
chris_wot 14y ago
They fail for Turkish PHP developers also. You're in good company!

celalo 14y ago

I is not capital of i in Turkish. Instead, İ is capital of i and I is capital of ı. They are two different letters.

endtime 14y ago
And this should affect class names why?
- batterseapower 14y ago
  Apparently identifier lookup is done case-insensitively...
  - deleted 14y ago
    [deleted]
Raticide 14y ago
No other language has this problem. The locale is irrelevant. The class name is just a series of bytes; it shouldn't need to transform the case.
- Permit 14y ago
  I believe it's because PHP supports case insensitive class names. It sounds like this will not change: https://bugs.php.net/bug.php?id=26575&edit=1 https://bugs.php.net/bug.php?id=26575&edit=1
  - shuzchen 14y ago
    Class and function names are case insensitive. But variables are not. Go figure that one out.
    - RobAley 14y ago
      I'd prefer them both to be one way or the other, but if they have to be different this is the right way to do it. For instance, functions can check to see what name the were called by (and process the call differently if we want to distinguish between cases). Variables can't do that so we must explicitly distinguish between them.

celalo 14y ago

I is not capital of i in Turkish. Instead, İ is capital of i and I is capital of ı. They are two different letters.

yuvadam 14y ago

It's kind of hard not to bash PHP for crap like this. Yes, the PHP ecosystem is friendly, easy, cheap, etc. etc. But as a programming language per se... Come on, PHP.

cocoflunchy 14y ago

I'm looking forward to the tenth birthday of this bug... Only 24 days to go !

robryan 14y ago

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. Granted given the usual pragmatism of PHP someone should have just hacked something in by now.

deleted 14y ago

[deleted]

j_col 14y ago

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. It is wildly successful despite this and many other bugs. 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. Sad that we have yet another anti-PHP posting hitting the front of HN in as many days, let the hating re-commence (again)...

deleted 14y ago
[deleted]
Raticide 14y ago
I think the people that attack it would rather see it die off than be "improved".
- davidw 14y ago
  I don't think those people understand the economics of programming languages. It's not going to die off any time soon, what with all the thousands of companies that use it, and zillions of lines of code. As someone who would rather not ever work with PHP again, the best thing is to simply focus on other languages and environments, helping to bolster those ecosystems.
  - lmm 14y ago
    Agreed, but publicising stupid problems with PHP actually does help that cause - it might push someone who's "on the fence" over to using a better system.
    - balac 14y ago
      I'm one of those on the fence. I've spent most of my programming life working on PHP and the recent barrage of negativity against PHP has made me more interested in learning another language, if just to make an educated comparison and see whether I am continue to use PHP "because I know it" or because it is actually good. I'm currently having a go at Python + Flask in my spare time.

Mithrandir 14y ago

I think this was a good explanation: "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: "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." Edit: Someone else later said the following (I'm wondering if it's true): "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."

simias 14y ago
But, why should the locale change the way PHP code is interpreted? Shouldn't LC_ALL="C" when parsing the code? Maybe it breaks if you embed unicode strings or something. What do other languages do?
- shuzchen 14y ago
  If it wasn't clear by the comments on the bug report or by the quoted sections of this comment's parent, let me rephrase it. This issue is entirely caused by the fact that PHP is case insensitive for classes and function names (but not variables, go figure). That is, if you define a class MyClass, you can instantiate it using MyClass or myclass or MYCLASS. You can call the functions from the standard library in whatever case either (so, array_map or ARRAY_MAP is fine). Based on the behavior of this bug, it appears that the way PHP handles this case insensitivity is that it just lowercases all class and function names before resolving them. And this bug in particular shows up for Turkish because 'i' is not the lowercase equivalent of 'I'. Pretty much all other modern languages are case sensitive, so I'd be surprised to find this issue elsewhere.

fmavituna 14y ago

It's also referred as The Turkey Test : http://www.moserware.com/2008/02/does-your-code-pass-turkey-test.html http://www.moserware.com/2008/02/does-your-code-pass-turkey-... http://www.codinghorror.com/blog/2008/03/whats-wrong-with-turkey.html http://www.codinghorror.com/blog/2008/03/whats-wrong-with-tu...

gokhan 14y ago

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.

TazeTSchnitzel 14y ago
Yep. .NET also has a nice set of string comparison classes for dictionary lookups to avoid exactly this kind of thing.
Draiken 14y ago
Unfortunately you can't compare .NET to PHP. Ever.
- billpg 14y ago
  They just did.

4qbomb 14y ago

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.

4qbomb 14y ago
This is simply proof of the demographic and blind nature of the Hacker News audience. Pathetic

alpb 14y ago

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. PHP is crap. Not even classical ASP had such bugs and it was perfectly passing the Turkey test (http://www.codinghorror.com/blog/2008/03/whats-wrong-with-turkey.html http://www.codinghorror.com/blog/2008/03/whats-wrong-with-tu...) and Unicode supporting languages didn't have such a bug. E.g. Java, Python. 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.

kalleboo 14y ago
If this is such a dealbreaker for developers in Turkey, why have none of them, in the 10 years this bug has been alive, submitted a patch for it? PHP is open source, it relies on code submissions. edit: not trolling, just curious. What drives people to complain about specific, well-defined open source bugs without any effort to fix it? I understand hard-to-nail down issues like user experience, but this shouldn't be that hard to plan out and fix independently.
- josteink 14y ago
  See Mithrandir's comment: http://news.ycombinator.com/item?id=4187943 http://news.ycombinator.com/item?id=4187943
- slurgfest 14y ago
  If there are viable alternative projects which never had that problem, you can save all the time rather than trying to salvage someone else's broken software. It's a lot less time and trouble. What reason do I even have for fixing your project? I don't owe PHP loyalty when it is broken for me. If there are viable alternative projects which are more responsive to bug reports, that is more promising for the future - if a second bug I see is reasonably likely to be fixed in the future, I can feel more confident basing my own code on it. People spend months and years writing apps on top of things like PHP and once they have the code they don't necessarily have a lot of choice. At that point maybe you fix the bugs in your dependencies rather than rewrite your own app. But when you have a choice, you don't adopt a tool which is going to leave you with this much technical liability. This is offered peacefully in an attempt to explain the question which seems to confuse you.

luminaobscura 14y ago

wow, it has been 10 years and no fix!

robryan 14y ago

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.

RobAley 14y ago
I'm assuming the original reason is lost in the mists of time, but one advantage it has when calling/using external/3rd party code is in style conventions. If in my code my convention is to use functionNames but in yours you use functionames or FunctionNames, I can still code in my style after include()ing your file. A small advantage, granted.
meepmorp 14y ago
> What was the advantage of case insensitive class and function names? The programmer can be sloppy/lazy and still have thing turn out largely as expected. If you're just learning how to program, this makes it a bit easier, since a whole class of possible problems goes away.

dools 14y ago

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? Or anywhere for that matter? 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. The choices are simple: 1) Fix the problem 2) Find a work around 3) Don't use PHP 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! 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.

gouranga 14y ago
You are the only reasonable voice on the matter I've heard so far. Infinite upvotes from me. We all know PHP has its shortcomings, but there appears to be a witch hunt going on here.
- josteink 14y ago
  We all know PHP has its shortcomings, but there appears to be a witch hunt going on here. I think some of the witch hunt comes in attempt to steer people away from a language which is badly designed and has a million bugs which cannot be fixed without breaking most of the existing code written for the language. Pestering a language like that is only fair. While I'm sure it gets tiresome for those who for whatever reason have to work or prefer working in PHP, it is only a polite gesture to the software-developers who has yet to take that dark path. If they can be dissuaded, they should.
  - gouranga 14y ago
    Granted it's horrible (I agree there), but it does solve a lot of problems rather quickly. I'd argue that it solves the problems in the '00s that Visual Basic did in the 90's. What I'd really like to see is a solution for '10s which fits that niche and is equally as productive, yet less horrible.

ObnoxiousJul 14y ago

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. PHP is cool, it is useful, it is a magnet for bad developers. This way they don't pollute our ecosystems.

jister 14y ago

If this is a known bug and it's been there for 10 years then why the hell did the developer STILL chose to use PHP in the first place?

Draiken 14y ago
Unfortunately on legacy systems someone else chose PHP for him a long time ago... Poor developer that has to deal with this stuff. Been there.

viraptor 14y ago

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. 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": - in declaration convert to lower-case and save, in usage convert to lower-case and lookup -> has to work - in declaration save original, in usage search all classes with case-insensitive compare -> has to work 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...

deleted 14y ago
[deleted]

dkhenry 14y ago

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. https://bugs.php.net/bug.php?id=62302 https://bugs.php.net/bug.php?id=62302

devgutt 14y ago

Bug is a bug is a bug is a bug

mikeash 14y ago

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. But come on. This language is complete crap. Code spontaneously fails depending on the locale? And the bug has been open for ten years 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. 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 far worse.

lonnyk 14y ago
> Code spontaneously fails depending on the locale? It doesn't spontaneously fail. The languages functions are case-insensitive and they documented this. [1] [2] When you change the locale to Turkish the letters change. Thus, the class name changes and no longer works as expected. So it is documented because it may not as expected, but it is not spontaneous. [1] http://www.php.net/manual/en/functions.user-defined.php http://www.php.net/manual/en/functions.user-defined.php [2] https://gist.github.com/3033533 https://gist.github.com/3033533
- viraptor 14y ago
  That's incorrect. It's not behaving as documented. Whether you compare in a case-sensitive or case-insensitive way "Info" should always match "Info". The bug results in a situation where it doesn't. I'd accept that you cannot reference class "info" using name "Info" in Turkish locale, but that's not the case here.
- mikeash 14y ago
  Nowhere in your documentation does it state that a class name cannot be accessed using the exact same, byte-for-byte identical name, depending on locale. Case sensitivity changing depending on locale would be weird, but at least vaguely sensible. Identical strings no longer matching is just plain wrong.
14y ago

patio11 14y ago

The situation is not helped by the frequent OSS community suggestion: "Just patch Turkish." while mumbling "Bloody non-ASCII ingrates."