Live data from Hacker News

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

bugs.php.net

21–30 of 135 posts

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

#21
post #11

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

I think the people that attack it would rather see it die off than be "improved".

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.

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

#23
post #4

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

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

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

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

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

#25
post #4

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

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.

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

#26
post #11

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

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) think would be required to make it a reasonable competitor to the existing options. (And the PHP community is not especially inclined to change. It took years for short array syntax to get added to the language. If something as obviously beneficial as that is going to be hotly debated, making real, breaking changes is impossible.)

Faced with the alternatives of trying to radically change PHP (which is, as I said above, impossible) or to use and improve other languages and frameworks, I think the choice is obvious. It was one thing 5-10 years ago when there weren't necessarily good or mature alternatives, but we have many choices now. In my opinion, it makes very little sense to use something with as much extraordinarly painful legacy baggage as PHP unless you have an exceptionally good reason for doing so.

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

#27
post #2

Words fail me.

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?

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

#28
post #21

Earlier quoted context omitted.

I think the people that attack it would rather see it die off than be "improved".

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.

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.

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

#29
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?

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.

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

#30
post #26
post #11

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

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" produces 5+ years of very bright, articulate, sometimes downright famous programmers making this same point about PHP. Most recently Jamie Zawinski at http://www.jwz.org/blog/2011/05/computational-feces/#comment...

Post reply on HN