Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We will try to stop fixing bugs in PHP

bugs.php.net

Post reply on HN
Print view View original

81–90 of 319 posts

Re: We will try to stop fixing bugs in PHP

#81

Post by gcb »

kevinalexbrown wrote: post #79

Leaving aside the irony of asking Rasmus to escalate the issue (this would be like complaining in an "Ask HN:" and suggesting that pg escalate the issue up the ycombinator chain), or whether the change was logical or not, I learned something cool from one aspect of Rasmus' response: ... there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a c…

if you can't do that trivial change on some convulated release system... You don't change php version either. Unless you are addressing security changes.

I think its very professional to not bump versions just for the sake of it.

release notes exist for a reason.

Re: We will try to stop fixing bugs in PHP

#82

Post by SomeCallMeTim »

Evbn wrote: post #42

Wait, endosquid writes tax software and expects that whenever a bit of data gets corrupted it should display an account balance of 0? Please share the name of this phenomenal software product.

I got stuck on "endosquid writes critical tax reporting software in PHP?!", actually.

Re: We will try to stop fixing bugs in PHP

#83

Post by gcb »

masklinn wrote: post #76
pelotom wrote: post #69

Earlier quoted context omitted.

Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.

> APIs are allowed to change in major releases On the other hand, significant breakage of 10 years-old APIs with not even release notes...

...of undocumented behaviour.

Re: We will try to stop fixing bugs in PHP

#84

Post by Xcelerate »

josephcooney wrote: post #53

The "is there anyone you can escalate this too" reminds me of a PERL newsgroup thread I saw where someone tried to rip Larry Wall a new one, asking (in a condescending way) him if he knew anything about PERL.

Haha, if you could find that again I'd like to see it!

Re: We will try to stop fixing bugs in PHP

#86

Post by jister »

In this kind of situation where there's a bug or limitation or some kind of issue with a language function we usually create a wrapper to handle the whatever rules we have internally within the company. In this case the empty string that is supposed to be NULL should be handled within that wrapper function. One function to modify instead of several places in the application.

Re: We will try to stop fixing bugs in PHP

#87

Post by earl »

masklinn wrote: post #76
pelotom wrote: post #69

Earlier quoted context omitted.

Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.

> APIs are allowed to change in major releases On the other hand, significant breakage of 10 years-old APIs with not even release notes...

tools shouldn't rely on undocumented behavior when passing out-of-spec parameters into functions. Relying on such behavior eventually gets you what you deserve.

Re: We will try to stop fixing bugs in PHP

#88

Post by rurounijones »

gurkendoktor wrote: post #20
rurounijones wrote: post #4

Earlier quoted context omitted.

Sorry I couldn't grok what your opinion on semver was. Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible). PHP made an backwards incompatible change in their code so it should have been a major version increase. So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver. Is that not your opi…

Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know. In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once. Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did. Ruby 1.9 broke "when 5:" in case s…

Yep, all those are true, I wasn't thinking. I was just focused on the hash syntax statement, thank you for all the good examples.

Re: We will try to stop fixing bugs in PHP

#89

Post by enjo »

chavesn wrote: post #39

Having number_format in so many thousands of places across so many products is indicative of pretty poor code. If you have bad code, you can hardly expect to be able to upgrade to new versions of the language seamlessly. Speaking of which, are they going to upgrade to 5.3 without testing all those thousands of places across all their products?

How is that indicative of bad code? That seems like a very big jump to make. If you're using PHP at the presentation layer you are probably doing a lot of this. Why would you write some sort of abstraction around number formatting when there is an abstract function to just do it for you?

This is particularly true if your applications are older and written before modern template systems made it a bit easier to abstract these concepts to filters and the like.

Re: We will try to stop fixing bugs in PHP

#90

Post by enjo »

Too wrote: post #77
TylerE wrote: post #15

Earlier quoted context omitted.

I disagree with point A. The old behavior makes a LOT more sense symbolically. I tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non-writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..

BOTH behaviors don't make sense. The right behavior is to throw an exception.

Absolutely agree, and that's PHP's biggest issue. It is constantly doing things like this instead of simply complaining and stopping things down like any sane system would.

If I were in charge of PHP, release 6 would be 5.4.4 with the standard library happily throwing exceptions on invalid input. That's it. The language would be 100% more useful instantly.

Post reply on HN