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

171–180 of 319 posts

Re: We will try to stop fixing bugs in PHP

#171

Post by AgentConundrum »

pacifika wrote: post #136
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…

A possible solution to this would be to put a policy together to only fix things like this in the next major version, not on the current line. As long as it's known that these are long term fixes people can prepare for them.

You're likely talking about the general case, not the OP, but I'd just like to point out that the submitter of the bug report was jumping from 5.1.6 to 5.3.1 (not to mention changing from Solaris to Red Hat, which could have its own issues) when he found this "error". 5.x releases are de facto "major" versions, even if only the minor version number changes.

It's entirely possible that this fix was made in a point release - it didn't jump out at me in the changelog, and I didn't feel like digging - but that's a moot point in this case, since even if the change was made with a major release like 5.3 this guy would still be upset.

Re: We will try to stop fixing bugs in PHP

#172

Post by Draiken »

lmm wrote: post #135
aniket_ray wrote: post #98

Earlier quoted context omitted.

I think you are entirely right. As Linux says "Kernel exists for its users". Pretty similarly, a platform (php/zend) exists for its applications. Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented. Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to wo…

Ulrich Drepper was vigorously in favour of it. If your application breaks, it's because it was written wrong.

Exactly. The only reason this bug got to production, is because the function accepted an empty string parameter in the first place.

Re: We will try to stop fixing bugs in PHP

#173

Post by andreasvc »

robryan wrote: post #154

In the same way that projects enforce a certain subsection of c++, it is probably best in PHP to not code anything in a way that relies on unusual quirks of the language to work. None of my code gets bitten here because I never passed number_format anything but numbers.

In my opinion weak typing is an unusual quirk, but there's no way to get around that. I really wonder kind of reasons could be given to defend it; I don't think a strongly typed language like Python is any harder because of its types.

Re: We will try to stop fixing bugs in PHP

#174

Post by Produce »

soc88 wrote: post #165
martenshinwarts wrote: post #110

Earlier quoted context omitted.

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

In PHP every code is amateur code.

While PHP is full of inconsistencies, it's far fetched to make a claim like this. Take a look at Symfony2 and try saying that it's amateur code.

Re: We will try to stop fixing bugs in PHP

#175

Post by spacemanaki »

jbm wrote: post #129
xd wrote: post #127

Earlier quoted context omitted.

"I use it for some piddly shit because that's what it's good for." The bigotry from this community when it comes to PHP has left me sick to my stomach.

Don't sweat it. Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress). I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around w…

> If you will ship faster and better with language X, go ahead and use it.

Absolutely, by all means, go for it. Godspeed.

> Languages are meaningless penis measuring contests of the IT world.

No they're not, and this is just insulting. I'm only an amateur PL nerd but there are people who have devoted their lives and careers to studying languages and thinking about the differences between them and how to design something practical, consistent, logically sound, beautiful, etc. To brush aside that work as meaningless is pretty narrow-minded. After all, some of that work helped even lowly PHP to stand taller on the shoulders of giants, and make it even possible to be a reasonable tool.

Re: We will try to stop fixing bugs in PHP

#177

Post by Terretta »

jheriko wrote: post #170
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…

i think you miss the larger point... any half way decent developer would never have this issue - breaking changes happen on every platform - or you should assume they will. use encapsulation properly (i.e. actually encapsulate, not just use a keyword meaning 'class' in the OO sense) and problems like this require single line of code changes to fix. even if you have them scattered across your code base what you then d…

> even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency

Take this line of reasoning far enough, and you're saying wrap every PHP function in your own function, so your programmers program in your synonym language instead of PHP, something like CoffeeScript vs JavaScript, perhaps.

I don't think using PHP (or any language) directly means you're a "shit programmer".

I think the care Python has taken between 2.x and 3.x is a better example of the type of care and concern and community awareness building around this exact sort of change that a language's benevolent dictators (Larry, Rasmus, Guido) should take when altering the philosophy of how the language should behave.

Re: We will try to stop fixing bugs in PHP

#178

Post by Produce »

buster wrote: post #121

All the discussion aside, there is so much wrong with it: First of all, why does the function even accept strings? There should be some eception happening. Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)

It accepts strings because PHP does not support type hinting for scalars.

Re: We will try to stop fixing bugs in PHP

#179

Post by Terretta »

wanderr wrote: post #123

I have to agree with the bug submitter in concept, if not in attitude. PHP is a dynamically typed language. As such, methods should expect surprises about the types of data received. Seriously, I've had PHP treat the same input as a string one time, an interface another, it's like it uses whatever is convenient at the time. If you neeeeed that data to be an int, cast it as an int, don't punish the user because type s…

Especially for a novice, formatting a field on a web form into a number, and seeing PHP format an empty field as zero, so you can carry on with your math, makes sense. "Oh, web parsing language, sees empty number field as zero, great!"

Principle of least surprise "for the novice web developer" says empty string to zero makes sense in this case.

Meanwhile, empty string with zero decimal places returning null would be less surprising to a pro, but in PHP, the first behavior would also be unsurprising to a pro.

Re: We will try to stop fixing bugs in PHP

#180

Post by snorkel »

Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually try doing this in PHP you get this:

   print number_format("",0);

   Warning: number_format() expects parameter 1 to be 
   double, string given in Command line code on line 1
So the poster willfully ignored the warning. You can fix this simply by casting the first arg as a numeric type:

   print number_format((int)"",0);
   0
Please, if you're this bad at programming and you willfully ignore warnings, don't file bugs, and please do not take a programming job at some place that does important things like air traffic control, banking, or life support systems.
Post reply on HN