Live data from Hacker News

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

bugs.php.net

91–100 of 135 posts

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

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

"I'd skip killing Hitler" would still be a bad idea. you cannot compare the shoa to language reform.

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

#92
post #85
post #75

Earlier quoted context omitted.

The issue only occurs when the locale is changed between registering and looking up the class.

Doesn't look like that from the bug report; there the locale is set first, then the class is defined and then looked up.

PHP registers classes (and functions) at parse time, not at execution time.

i.e. this will print "bar":

    

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

#93
post #82

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…

> 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

[2] https://gist.github.com/3033533

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

#94
post #82

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…

Of course, this isn't an article critical of PHP and I'm sure those defenders would just as readily state 'every time PHP appears on Hacker News the PHP-haters come out."

While I tend to agree that I would not use PHP for new projects, I would disagree that it's indefensible. All you need to defend it is, "it's easy." In the sense of, "it's nearby, it's within reach." If it happens to be the language installed on your system, its use is automatically defensible on those grounds alone.

It might not nurture you and love you and cherish you; hell, it may abuse you at times, as any language with idiosyncrasies does. It might even have more idiosyncrasies than other languages do. But those do not make a relationship indefensible -- merely difficult. And in some cases, the difficulty makes the love even more binding -- which is why we still have people who program in low-level languages, for example, even though those have all the more tendency to abuse you for the tiniest mistake you make.

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

#95
post #93
post #82

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…

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

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.

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

#97
post #89

Earlier quoted context omitted.

I doubt that breakage would be minimal. I'm not as certain as you that most code does honor the spelling of class and method names, but even if we assume that this is the case I'd assume that there are tons of undetected errors. Currently, there's just no way to test that you're using the proper spelling, so nobody does.

It would be trivial to write a command line tool to check (and maybe automatically fix) those typos. Incorporating it into a major new version also ensures everybody has enough time to prepare - and in case of hopeless and unfixable legacy apps: there is always the option not to upgrade. Breaking changes in programming languages are not that uncommon, C# and Perl spring to mind from personal experience, but also to a…

I'm not against changing that behavior since it's arguably stupid and inconsistent [1], but I'm wary of "trivial" changes. It's not only apps that need fixing, pretty much every library needs checking (and maybe fixing). This cannot be done with a commandline check, since classnames can be constructed on the fly, called via eval() or call_user_func() etc. Class names may be loaded or even defined on the fly (the SOAP Pear Extension does this to create proxies). All those cases can only be checked by executing the program. It's probably a good change, but this is anything but trivial.

[1] actually, I don't care at all since I moved on to greener pastures.

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

#98
post #82

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…

  > Code spontaneously fails depending on the locale?
Code spontaneously hangs when converting 2.2250738585072012e-308? Now count how many languages were affected by that.

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

#99

Earlier quoted context omitted.

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.

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

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.

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

#100
post #51

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…

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

it's really not that simple. Check the "Fold Case" section of the Letter Case article on Wikipedia; the explanation is much better:

http://en.wikipedia.org/wiki/Letter_case#Unicode_case_foldin...

It's not PHP's fault that accurately performing case transformations across locales is difficult; it's just actually very difficult. The solution isn't to "fix" the process of transforming letter case; the solution is to simply not transform the names of your identifiers. Unfortunately that is simple only in a very isolated setting; in the real world, doing such a thing is liable to break a lot of software.

This is a really good example of the problem at hand:

>The Greek letter Σ has two different lowercase forms: "ς" in word-final position and "σ" elsewhere.

The identifiers are lowercased multiple times; first at parse time, presumably using the locale of the OS, some setting in php.ini, or some fixed locale. (it doesn't, in practice, matter where this initial locale is set; it just matters that it's set at parse time.) It's then lowercased again at runtime; if the locale was changed at runtime, such that the casing rules in the two locales produce any differences, the identifier will not be found.

I'm not saying this to defend PHP; just to shed some light on the case-folding problem. Having case-insensitive identifiers is a design mistake.

Post reply on HN