Live data from Hacker News

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

bugs.php.net

121–130 of 135 posts

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

#121

Earlier quoted context omitted.

PHP is so incredibly bad as to have no redeeming qualities to the language whatsoever other than its simplicity in deployment. Whereas I can have reasoned conversations with proponents of most modern languages, PHP is simply and unequivocally a complete and total failure of a language, and there is resultantly absolutely no room for concession when discussing the language. PHP is broken and should never be used, and…

> PHP is broken and should never be used, and if there are use cases that the alternatives don't address, we should work to address them. What alternatives meet your standards of not sharing qualities of PHP while matching the quality of simplicity in deployment (of which Python and Ruby instantly fail)?

I don't think any language matches the simplicity of deployment, but outside some very constrained use cases in environments where there can not be sufficient technical expertise and staffing, deployment doesn't begin to justify the technical travesty of PHP.

In a corporate technology organization there is no justification.

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

#122

Earlier quoted context omitted.

Yes I realise that

In that case, why not just use any of the existing developed alternatives rather than developing an entire new PHP replacement from scratch?

Because the alternatives suck in different ways.

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

#123
post #91

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

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

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

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

#124

Earlier quoted context omitted.

Who are you to decide that? I am one of those who chose to work with PHP, and I'm getting more than tired about that witch hunt, to a point where I would actually punch someone. I do realise PHP is not ideal, but as I always say, in the end it get shits done, and the vast majority of those problems or "design flaws" does not affect 99.9% of the community. Most of the people who bitch about it are not even users, in t…

I suspect that the only people who can defend PHP on technical merits are people who have yet to try something better and have yet to realize just how much better most other options out there are. If that describes you, I am sorry for you, and deeply encourage you to take on something new on the side, in a different language. Just for fun, learning and exploration. Just to let your mind get a feel for how the world c…

That's a bit patronizing.

Having dealt with every language under the sun over the last 20 years, PHP still has an as yet unbeatable sweet spot when it comes to getting stuff done.

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

#125

Earlier quoted context omitted.

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

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

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.

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

#126
post #21

Earlier quoted context omitted.

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.

To clarify, "die off" means "stop getting NEW projects," not "everyone spontaneously destroys existing legacy apps." That has never been on the table. When you say you don't want to use PHP again and want to focus on other languages, you are saying you want PHP to die off.

I'm certainly no fan of PHP, you're correct, but people will continue to do new things in it for many years to come, because that's what they know.

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

#127
post #104

Earlier quoted context omitted.

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…

> ...badly designed... > ...and has a million bugs... > ...cannot be fixed... > Pestering a language like that is only fair. > ...who has yet to take that dark path Wow that's a lot of emotive language. Like the man said, witch hunt.

Yep, there's no need for language like that when dispassionate facts can get the point across just as well:

1. PHP contains a bug which makes class and function names containing certain letters, like I, fail when the code is run in certain locales.

2. This bug has been open for ten years and has not been fixed. It's not likely to ever be fixed.

3. Many similar bugs exist in the code base, due to the PHP team's approach to language design.

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

#128
post #57
post #37

Earlier quoted context omitted.

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?

No matter how you do it, a class name should always match when looked up with an identical string.

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

#129
post #65
post #44

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

It might not be an easy fix if you're not familiar with PHP's guts. It's the kind of fix that can induce a lot of unexpected regressions. Not wanting to fix a bug because it's not worth the time or risks breaking backward compatibility is perfectly fine by me. But at least take a decision and say something. If they don't plan on fixing it they should say something like "We believe this is a minor bug that only concer…

The "strawman" you're referring to was in response to this:

http://news.ycombinator.com/item?id=4188167

specifically the complaint that this problem manifests with lots of off-the-shelf software (although I suppose he didn't specify FOSS in his original comment).

However, I wasn't directly responding to that guy, I was more responding to what I feel has been aptly described as a "witch hunt" by others on this page.

It might not be an easy fix if you're not familiar with PHP's guts

10 years is a long time for someone to have the chance to get familiar with it.

Even if you assume that for 8 years, everyone was saying "oh, it will get fixed some time" even 2 years is a long time for anyone affected by this problem seriously enough to become familiar enough with PHP to fix the problem if that's the path that will produce the most value for them (ie. if there's enough value in some existing codebase or off the shelf software to warrant fixing this if there's truly no other workaround).

Still, I can see the sense in promoting major issues like this with PHP, but posting the bug report on the front page of HN is far less useful than, say, writing a blog post about it with some case studies of where the problem has been manifest, how people have dealt with it, the history of the bug, etc.

Actually that's a good blog post, might put it on my list ;)

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

#130
post #74

Earlier quoted context omitted.

PHP could just use the approach NTFS uses on Windows and convert to upper case instead: http://blogs.msdn.com/b/michkap/archive/2004/12/02/273619.as...

Which would not help in this case, since in turkish the upper-case representation of `i` is not `I` but a different symbol. So the class you're looking for would not exist.

Oops - looks like you're actually right there. For some reason, I thought I'd read that i and ı were both mapped to I.
Post reply on HN