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

101–110 of 319 posts

Re: We will try to stop fixing bugs in PHP

#101

Post by LawnGnome »

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

Even given that it was undefined behaviour to start with, it's the very first incompatible change listed at http://au2.php.net/manual/en/migration53.incompatible.php — you'd hope a professional developer would at least glance at that document when migrating a codebase to 5.3.

Re: We will try to stop fixing bugs in PHP

#103

Post by kenneth »

There are countless reasons to bash on PHP because, frankly, it is a pretty terrible language[1]. However, this is not a valid reason. The bug reporter is being idiotic and needlessly disrespectful, and is making a big deal out of something that can be easily fixed with a simple `sed` command, as Rasmus demonstrated.

And, to be honest, he is clearly demonstrating the fact that he's a pretty poor developer, and that he doesn't have the necessary qualifications to be writing software that manages people's retirement funds. Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP.

[1]: Coming from somebody who built a very successful startup on top of PHP.

Re: We will try to stop fixing bugs in PHP

#104

Post by Yver »

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.

Indeed, it's amazing that the same person could say "We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages" and "Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning."

They are very thorough with testing their super-important tax software. Well, except they ignore uninitialized variables, but I hear those are A-OK in accounting.

Re: We will try to stop fixing bugs in PHP

#105

Post by Groxx »

So the options are:

  1. Change thousands of lines of code (probably `sed`-able)
  2. Patch PHP to re-introduce the original bug/feature
  3. Downgrade PHP back to the version that had the
     bug/feature you were relying on
Why is option 3 not considered in this thread? It was working before, and evidently they can control the version of PHP (since they can patch it). If upgrade breaks X, and you rely on X, don't upgrade. If you need to upgrade for Y, do so, and fix X. That's just how such things work.

Re: We will try to stop fixing bugs in PHP

#106

Post by masklinn »

earl wrote: post #87
masklinn wrote: post #76

Earlier quoted context omitted.

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

Or one could expect the language to behave coherently (tall orders for PHP, I know) and consider that it will use whatever is provided to it in the usual manner in which it treats non-numbers in a number context. Especially when the function has behaved in this manner for a decade.

Re: We will try to stop fixing bugs in PHP

#107

Post by masklinn »

LawnGnome wrote: post #101
masklinn wrote: post #76

Earlier quoted context omitted.

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

Even given that it was undefined behaviour to start with, it's the very first incompatible change listed at http://au2.php.net/manual/en/migration53.incompatible.php — you'd hope a professional developer would at least glance at that document when migrating a codebase to 5.3.

> Even given that it was undefined behaviour to start with

On the other hand, 1. high-level languages have no reason to have UBs, especially for the trivial calling of a core function and 2. one could expect behavior in this context to be coherent with behavior in userland contexts. In PHP, using strings in a numeric context wasn't — last time I checked — considered abnormal, no matter how little sense it makes. One could therefore expect the relevant coercitive calls to be performed as they would usually be.

> it's the very first incompatible change listed

It is very ambiguously worded: the clause states functions will return NULL when passed incompatible parameters, but in all of PHP's userland code strings are very much compatible with floats. I would therefore submit that — in the context of being a user of PHP — the clause does not apply to this case as the value passed in is absolutely compatible with parameter expectations.

Re: We will try to stop fixing bugs in PHP

#108

Post by johnny22 »

TwoBit wrote: post #85

In most mature programming languages we resolve this kind of dispute by pointing to the Standard. Is that not possible with PHP?

Well that's what happened to this guy. He relied on unstandard/undefined behaviour and when php switched to a standard parameter parser it broke his app.

Re: We will try to stop fixing bugs in PHP

#109

Post by masklinn »

steve8918 wrote: post #28
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 ..

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.

> he question is more similar to "Can you please tell me the number format of ".

Well in PHP, the number for is 0, so it would stand to reason that the formatted number for is 0 as well.

Re: We will try to stop fixing bugs in PHP

#110

Post by martenshinwarts »

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…

"This bug report highlights the problems you run into if you use it for serious work."

Indeed. Passing an empty string for a parameter which is expected to be a float is SUCH serious work.

"if it breaks your stuff then tough shit because we're a bunch of amateurs."

You say that, but it rather seems like it broke amateur code.

Post reply on HN