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

191–200 of 319 posts

Re: We will try to stop fixing bugs in PHP

#191

Post by xd »

DHowett wrote: post #186
snorkel wrote: post #180

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…

The headline of this post is such because it is quoting a PHP developer on a point made in a later comment on the report.

The quote was tongue in cheek.

Re: We will try to stop fixing bugs in PHP

#192

Post by Darkstar »

Everybody was in the wrong here. The developer should've written better code. I'm a PHP developer and I've learned that if the input is that important, I need to cast it. I've used C++, C#, and Java and I like strict typing. If your application is that sensitive then maybe it should've casted the input to ensure the output is consistent.

As for Rasmus, I think he could've explained why it's a "won't fix" type bug in a slightly more diplomatic fashion, though I can't say I would've handled it any differently. He's completely right as to why the behavior shouldn't change. Finally, bjori's response was completely unnecessary, inflammatory, and downright rude.

This has shown me the worst of the PHP community. I'm not ashamed, just more wary.

Re: We will try to stop fixing bugs in PHP

#193

Post by TillE »

webreac wrote: post #125
gcb wrote: post #81

Earlier quoted context omitted.

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.

As far as I understood, the release notes were not very explicit or complete (the list of impacted functions were missing) on this issue. Recently I have encountered a problem with redhat migration: /usr/bin/X11/xwd was "moved" to /usr/bin/xwd. I have not found anything in the release note. It is not enough to ask people to read the release notes, these release notes should be complete and usable.

The point is that the release notes will tell you if there are security flaws fixed.

There's no substitute for actually testing your code with a new environment before deploying it.

Re: We will try to stop fixing bugs in PHP

#194

Post by StavrosK »

SomeCallMeTim wrote: post #82
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.

alkavan's comment on this thread is dead, reposted here:

Yup, indeed this is the main problem here. I work with PHP for many years, but i would not suggest using PHP layer as core of my "Taxing software", PHP is not statically typed means it's not suited well for this job, in e-commerce sites i built in past there were always problems when it gets to tax calculations, you learn to deal with it by wrapping your calculation code in the right way and testing it currently.

It is probably the case when unskilled programmers just used number_format() directly instead of wrapping it with "Tax" class that does that you want it to do, and nothing else. it was indeed common in PHP 4, but we have moved since then.

Re: We will try to stop fixing bugs in PHP

#195

Post by Xylakant »

Tloewald wrote: post #151
Xylakant wrote: post #140

Earlier quoted context omitted.

None of the decisions listed here were "obscure" design decisions and none of your examples indicates that ruby is unstable. Specifying the source encoding in 1.9 is only required if you have string literals in your code that are not in the default encoding. That should be a rather rare case, in fact pretty much none of my code files has the encoding header. Ruby 1.8 was not encoding aware, so Strings were just pure…

So you dismiss a bunch of valid breaking changes because you weren't affected by them and then cite one you know about. Well played, sir.

Well no, all I'm saying is that they indeed were breaking changes, but not "obscure design decisions".

All of them were made for a reason and the reasons were public. Some of them had easy workarounds (like a commandline switch) Most of them happened at the transition of a major release and made the introduction of major features possible. Ruby 1.8.6/7 was supported for years after the transition for people that had code that's hard to change or adapt. Hey, one of the examples the OP posted is "we had code relying on an obvious parser bug, and it breaks since they fixed it." So well, call it "dismiss" if you want. I call it "evolving a language"

I've been working with ruby at the point when 1.8 moved to 1.9 and it was quite a change. Pretty much every library that handled strings broke, but I don't see any way around that and still get encoding support. Many people actually forget that ruby 1.9 is actually what should have become 2.0.

I've been affected and patched several libs to work properly with 1.9.[1] There's absolutely no reason to become snarky.

[1] most of the changes required were trivial, still it's breaking and annoying.

Re: We will try to stop fixing bugs in PHP

#197

Post by xd »

soc88 wrote: post #164
mcrittenden wrote: post #162

Earlier quoted context omitted.

I'm pretty disappointed to see comments like these around here, and not getting downvoted. This comment adds nothing to the conversation, and criticizes PHP with no factual basis or explanation.

Why? He said that the design principle of this method is in line with the rest of PHP, that's a correct and valid observation.

So how would you propose changes are made to an "API"? Never? The change was made in a new version, with the changes clearly laid out in the changelog .. what more do you want?

It's funny. PHP gets a bashing for the rotten bits .. when the rottern bits get patched up it gets a bashing for breaking BC.

Anyway, I don't think you understand just how empty that attack was. Frankly it was nothing more than the ramblings of an obviously very inexperienced developer.

Re: We will try to stop fixing bugs in PHP

#198

Post by ivanhoe »

Issue here is not whether it can be fixed, anything can be fixed. Issue here is why in the world they have changed things in a such way to break the old code?! Was it necessary? I don't think so... I understand the need to re-factor, and making some old stuff obsolete along the way, of course, but it's not the case here. It's just that someone wasn't really playing attention to this. And this type of negligence to the details is really killing php as language. If after 10+ years in php I need to re-read the manual every now and then to make sure if the things are still working like the last time, it's just crazy..

Re: We will try to stop fixing bugs in PHP

#199

Post by ericingram »

Darkstar wrote: post #192

Everybody was in the wrong here. The developer should've written better code. I'm a PHP developer and I've learned that if the input is that important, I need to cast it. I've used C++, C#, and Java and I like strict typing. If your application is that sensitive then maybe it should've casted the input to ensure the output is consistent. As for Rasmus, I think he could've explained why it's a "won't fix" type bug in…

This is exactly how I feel about it.

I think it's an example of how not to interact in a community, from both angles. Also, I can't stand the notion that open source developers are "volunteering" their effort. All programming is voluntary in the sense that you are making a free choice to do it and most likely gaining capital (social or financial) in the process. I voluntarily build software and give or sell it to others all the time.

Post reply on HN