Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bugs.php.net

Post reply on HN
Print view View original

51–60 of 135 posts

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

#51

Post by pieter »

shuzchen wrote: post #29
simias wrote: post #20

Earlier quoted context omitted.

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?

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 whate…

That still doesn't make sense. If 'i' is not the lowercase equivalent of 'I', then the lowercasing should just result in another letter, right? The only thing that could cause the bug is if it uses two different ways of lowercasing (perhaps one when registering the class, and another way when looking up the class).

The mapping between uppercase and lowercase can be completely arbitrary, and as long as it's used consistently you shouldn't get these kind of bugs.

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

#52

Post by kalleboo »

klmr wrote: post #35
shuzchen wrote: post #29

Earlier quoted context omitted.

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 whate…

Well, VB.NET is case insensitive yet the problem doesn’t crop up there because it’s not braindead enough to use the same locale while compiling & executing. Yes, I get that PHP code isn’t compiled in a separate step but there still is no reason for it to use a user-defined locale. It should use the C locale, end of story. I don’t understand why this isn’t trivial to fix. Is there any place where PHP depends on a user…

Class names can crop up during execution as well though. This is valid PHP:

  $classname = $row_I_got_from_mysql['classname'];
  $object = new $classname;
I'm sure this can still be solved though. It's not trivial, but it's not "takes over 9 years to fix" complex either.

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

#53

Post by zokier »

dasil003 wrote: post #12
kitsune_ wrote: post #2

Words fail me.

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 unexpectedn…

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.

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

#55

Post by kalleboo »

alpb wrote: post #39

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://w…

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.

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

#56

Post by ebiester »

gokhan wrote: post #27
ebiester wrote: post #10

Earlier quoted context omitted.

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!"

Take the case of software insisting on state input hence unusable outside US. Do you blame the error to George Washington?

Ş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...)

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

#57

Post by pilif »

klmr wrote: post #37
pilif wrote: post #25

Earlier quoted context omitted.

True for languages which are case-sensitive. Other languages like PHP (partially), BASIC or Pascal are case insensitive, so lookup has to be done case-insensitively which means that case has to be normalized, so transforming case of identifier becomes necessary. If it can't be done consistently, that's a problem.

So you use a culture-invariant locale for parsing. Still not a problem.

How do you lowercase in a culture-invariant locale? Or do you mean english?

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

#58

Post by meepmorp »

robryan wrote: post #42

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.

> 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.

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

#59

Post by viraptor »

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...

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

#60

Post by Draiken »

gokhan wrote: post #24

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.

Unfortunately you can't compare .NET to PHP. Ever.
Post reply on HN