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

71–80 of 319 posts

Re: We will try to stop fixing bugs in PHP

#71

Post by lnguyen »

blantonl wrote: post #55
reitzensteinm wrote: post #30

Earlier quoted context omitted.

A wrapper function is absolutely the right way. Instead, he decides to modify the PHP source and recompile it , effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain. Wow.

Spot on. He doesn't want to update his 50+ applications, but he wants to patch PHP and deal with the deployment of that to all the servers that support those 50+ applications. And he admits that he's not a C++ coder. Sounds like a change management nightmare.

But it's only one change.+

+ Technically true. The scope will be equivalent to 50+ change tickets. And he'll be able to blame someone else for any issues that result.

Re: We will try to stop fixing bugs in PHP

#72

Post by masklinn »

thought_alarm wrote: post #63
damian2000 wrote: post #23

Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

Rasmus comes across as a little kid. Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure…

> We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs.

Well that's pretty much PHP in a nutshell, no news there.

Re: We will try to stop fixing bugs in PHP

#73

Post by mturmon »

reitzensteinm wrote: post #30
soulclap wrote: post #19

I understand that the bug reporter is in a bad situation but this is definitely an edge case and passing an empty or whatever non-numeric string to a function that is clearly meant for formatting numbers doesn't really seem like good style. is_numeric(), is_float() and casts are available for a reason. So I guess the answer is ultimately 'deal with it'. That said, I don't see this taking 'months' either, they could j…

A wrapper function is absolutely the right way. Instead, he decides to modify the PHP source and recompile it , effectively forcing him to maintain a fork of PHP, as if somehow that magically takes less effort to develop and QA resources to maintain. Wow.

Just goes to show that the issue had become personal, not technical. The complainer was bent on showing Rasmus that his code was wrong (by implementing the change himself), not on fixing the problem in the easiest way.

Re: We will try to stop fixing bugs in PHP

#74

Post by soulclap »

thought_alarm wrote: post #63
damian2000 wrote: post #23

Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

Rasmus comes across as a little kid. Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure…

Bad code style will eventually get you in trouble in any language or environment, bugs can occasionally turn into features and updates will always require testing, this is not a PHP specific problem at all.

Re: We will try to stop fixing bugs in PHP

#75

Post by dpark »

lifthrasiir wrote: post #35
soulclap wrote: post #24

Earlier quoted context omitted.

Well, exactly. It doesn't say what happens, so pass floats or expect the unexpected. I get your point but I don't think I have ever seen documentation anywhere that covers all of the possible 'abuse' scenarios.

It is possible to add a catch-all clause to the documentation. For example any non-float argument is converted to float via floatval(), or raises an error, and so on. This behavior can be made consistent across every API so that the documentation has only one place to describe it. PHP is missing this either AFAIK.

> This behavior can be made consistent across every API so that the documentation has only one place to describe it.

Sounds like that's what 'zend_parse_parameters' does, actually.

Re: We will try to stop fixing bugs in PHP

#76

Post by masklinn »

pelotom wrote: post #69
thought_alarm wrote: post #63

Earlier quoted context omitted.

Rasmus comes across as a little kid. Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure…

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

Re: We will try to stop fixing bugs in PHP

#77

Post by Too »

TylerE wrote: post #15
quink wrote: post #7

Earlier quoted context omitted.

A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass…

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.

Re: We will try to stop fixing bugs in PHP

#78

Post by pelotom »

TylerE wrote: post #15
quink wrote: post #7

Earlier quoted context omitted.

A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass…

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

I tell you you have 12/0 apples. Write the number of apples you have on a piece of paper. Some "functions" are not defined for all inputs. Better to give a "that doesn't make sense" answer than a bogus answer.

Re: We will try to stop fixing bugs in PHP

#79

Post by kevinalexbrown »

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 change like this that others in your situation have now accounted for, tested and deployed in production for many months ... -- rasmus.

Good decisions don't always mean everyone goes home happy. Whether or not the change was good or bad, reversing it now could negatively impact anyone else who already adjusted. If it means "MONTHS" of work for this guy, in order to save "MONTHS" of work for 100 others who use PHP, so be it.

Even if we were to take a leap of faith and assume it was a bad decision by Rasmus to make the change in the first place, it's been done. Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

Re: We will try to stop fixing bugs in PHP

#80

Post by mturmon »

phene wrote: post #43
steve8918 wrote: post #28

Earlier quoted context omitted.

I don't agree with your analogy. The question is more similar to "Can you please tell me the number format of ". How can the answer to an unfinished question be "0"? 0 is an actual valid answer, when people are asking for number_format(0, 0). In this case, NULL is definitely more appropriate, because the input is invalid.

What's the numeric representation of the volume of ? 0 dB

Since dB are a log scale, more properly, it would be -Inf dB.
Post reply on HN