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

61–70 of 135 posts

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

#61

Post by jeltz »

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…

If they only had used Ï and ï instead everything would have been much simpler.

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

#62

Post by dkhenry »

This is my biggest problem with PHP. Aside from poor language construction , and the plethora of poorly written code the core language has lots of problems in it. When upgrading to PHP 5.4.3 I found six or seven show stopper bugs in PHP and some of its extensions ( one of which has never worked ). I am still waiting on the fix to one of them. https://bugs.php.net/bug.php?id=62302

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

#63

Post by josteink »

kalleboo wrote: post #55
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…

See Mithrandir's comment: http://news.ycombinator.com/item?id=4187943

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

#64

Post by Draiken »

jister wrote: post #54

If this is a known bug and it's been there for 10 years then why the hell did the developer STILL chose to use PHP in the first place?

Unfortunately on legacy systems someone else chose PHP for him a long time ago... Poor developer that has to deal with this stuff. Been there.

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

#65

Post by simias »

dools wrote: 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 concerns a small number of users. In order to fix this we'd need to change X, Y and Z and make sure we don't introduce regressions. If you want to try and do it we'll be glad to review your patches. In the meantime you can use this workaround: [...]".

I hate it when I submit a bug report and it's being ignored. You also build a strawman argument with the "lot of open source software that you wanted to use for free". It's a bug and should be fixed (even if the fix is closing the ticket as "wontfix").

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

#66

Post by lloeki »

j_col wrote: post #36
codinghorror wrote: post #30

Earlier quoted context omitted.

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

> Does their hard work deserve this constant ridicule?

Nobody seriously criticizing PHP is ridiculing people working with it. On the contrary, I personally applaud people having to, and succeeding at extracting diamonds with a broken pickaxe.

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

A "better" PHP would be at its core so entirely different and incompatible with the current PHP that calling it "PHP" would be a complete misnomer. Since it would be such a different language/platform with only vague syntactic and semantic similarities, one might as well invest its time in the better designed, actively developed, battle-tested, currently available alternatives.

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

#67

Post by Tloewald »

LawnGnome wrote: post #34
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?

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.

I don't think it's "obvious" at all. The problems caused by case sensitive identifiers are legion, especially in dynamic languages with implicit declaration. It's not at all clear to me that this problem is of case insensitive identifiers and not simply in PHP's implementation.

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

#68

Post by davidw »

balac wrote: post #50
lmm wrote: post #28

Earlier quoted context omitted.

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.

I'm one of those on the fence. I've spent most of my programming life working on PHP and the recent barrage of negativity against PHP has made me more interested in learning another language, if just to make an educated comparison and see whether I am continue to use PHP "because I know it" or because it is actually good. I'm currently having a go at Python + Flask in my spare time.

Recent? I never cared for it, and I know that was a common sentiment amongst many 'HN' type people (even though there was no HN then), but until Ruby on Rails came out, I had never found something that had everything I needed and wide appeal. At the time, for me, that meant continued work on Apache Rivet ( http://tcl.apache.org/rivet/ ) , which in a lot of ways was better than PHP, but always suffered from not having a lot of users.

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

#69

Post by Tloewald »

j_col wrote: post #36
codinghorror wrote: post #30

Earlier quoted context omitted.

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

It seems to me that the kicker is the obviously superior alternatives, such as python, ruby, and JavaScript, don't offer the ease of deployment that php has via mod_php, and instead insist on the developer writing a web server. While there are advantages (performance, control) to the web server approach it is clear that there are advantages (simplicty) to being able to stick code snippets in web pages.

If you could deploy (say) python-decorated web pages via apache (on el cheapo hosting services) versus write yor own server and figure out how to host it then the problem would be solved. We have the languages, just not the ecosystems.

Obviously I'm not the first to observe this. Mod_python exists, it's just not popular.

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

#70

Post by billpg »

Draiken wrote: post #60
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.

They just did.
Post reply on HN