Live data from Hacker News

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

bugs.php.net

31–40 of 135 posts

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

#31
post #19

Earlier quoted context omitted.

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…

Just my curiosity, how do you know that they were short on vowels?

[deleted]

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

#32
post #19

Earlier quoted context omitted.

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…

Just my curiosity, how do you know that they were short on vowels?

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), 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)

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

#33
post #23

Earlier quoted context omitted.

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.

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

Class and function names are case insensitive. But variables are not. Go figure that one out.

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

#34
post #20

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…

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?

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.

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

#35
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…

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-defined locale for parsing?

EDIT: “trivial to fix” as in, doesn’t cause regression, not necessarily that it’s a small change to the code base.

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

#36
post #26

Earlier quoted context omitted.

Responses like this to people who don't like PHP are just as bad as the people constantly and loudly attacking it. Neither accomplishes anything other than building animosity. Your suggestion that people improve PHP instead of attacking it is naive. PHP is, as you said, a big legacy open source project. As a result of that, it's basically impossible to make the extreme, breaking changes that many people (me included)…

After 5+ years of eloquent, smart programmers* posting long, well researched screeds about what's deeply broken with PHP's design at the most fundamental levels, there is no other conclusion to be reached. The only way to improve PHP is to replace it, and we have a long way to go to get there. * Note that I am not including myself in this list. But any trivial search for "what's wrong with PHP", much less "PHP sucks"…

> After 5+ years of eloquent, smart programmers* posting long, well researched screeds about what's deeply broken with PHP's design at the most fundamental levels, there is no other conclusion to be reached.

Issuing holy decrees from their ivory towers more like. Meanwhile, lots of tremendously successful companies doing real work in PHP each and every day, at the coal face, where it matters. Does their hard work deserve this constant ridicule?

> The only way to improve PHP is to replace it, and we have a long way to go to get there.

Agreed. When something better comes along, I'll start using it (like how I switched from Perl to PHP a long time ago). The problem is, many "eloquent, smart programmers" are too busy "posting long, well researched screeds" to spend some time making PHP better (or making a better PHP).

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

#37
post #25

Earlier quoted context omitted.

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.

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.

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

#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://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.

Post reply on HN