We will try to stop fixing bugs in PHP • Hacker News Board

Re: We will try to stop fixing bugs in PHP

#51

Post by aethr » Fri, Jun 22, 2012, 4:32 AM UTC

lifthrasiir wrote: post #16

mparlane wrote: post #3

I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?

Regardless of the prior behavior, that particular behavior was not documented [1] and subject to change. I do think it is PHP's (very big) fault that the proper documentation on various edge cases is missing, but it is a bit too much to disallow PHP to change undocumented behaviors. That said, the proper documentation is not enough (and PHP does not get this right either); it's rather a mere prerequisite. [1] http://…

The specific usecase the bug reporter has provided DOES raise a warning, which he has intentionally routed to /dev/null

php -r 'print number_format("",0) . "\n";'

PHP Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1

Re: We will try to stop fixing bugs in PHP

#52

Post by jessedhillon » Fri, Jun 22, 2012, 4:38 AM UTC

phaus wrote: post #22

ahi wrote: post #11

Earlier quoted context omitted.

To standardize PHP is to create a new language not named PHP.

If you read it until the end you will find out that the technical support representative talking to the irate customer is the creator of PHP. As the creator, PHP can be whatever he decides he wants it to be.

PHP can be whatever he decides he wants it to be

What you're describing is whimsical, not standardized.

Re: We will try to stop fixing bugs in PHP

#53

Post by josephcooney » Fri, Jun 22, 2012, 4:39 AM UTC

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.

Re: We will try to stop fixing bugs in PHP

#54

Post by pippy » Fri, Jun 22, 2012, 4:40 AM UTC

So developers complain that PHP is not standardised, but when it is in a major version upgrade developers complain that it's becoming standardised?

Re: We will try to stop fixing bugs in PHP

#55

Post by blantonl » Fri, Jun 22, 2012, 4:40 AM UTC

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.

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.

Re: We will try to stop fixing bugs in PHP

#56

Post by piggity » Fri, Jun 22, 2012, 4:43 AM UTC

josegonzalez wrote: post #18

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…

The following does not work anymore in 1.9 (at least when it was released, who knows if they reverted the change): {"a", "b"} And there were plenty of gems and small scripts online I was able to get working just fine under 1.8.7 but not 1.9. Thankfully that is largely no longer the case, as things have been updated or replaced. String class was also given a nice kick in the ass, at least in regards to iteration. Woul…

I don't "really mind" if it breaks totally (i.e. throws an appropriate exception or doesn't parse the syntax check).

I find it much more irritating when the behaviour subtly changes and introduces edge cases that may not be picked up in testing / normal usage.

Re: We will try to stop fixing bugs in PHP

#57

Post by MBlume » Fri, Jun 22, 2012, 4:44 AM UTC

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

Downvoted for cleverness.

Re: We will try to stop fixing bugs in PHP

#58

Post by soulclap » Fri, Jun 22, 2012, 4:46 AM UTC

Related article about the same bug report: "When does a bug turn into a feature?"

http://lwn.net/Articles/369505/

Re: We will try to stop fixing bugs in PHP

#59

Post by iamumassthrower » Fri, Jun 22, 2012, 4:48 AM UTC

josegonzalez wrote: post #34

gurkendoktor wrote: post #20

Earlier quoted context omitted.

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…

I used it as the example simply because it is normally a language that is touted quite superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all. Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.

Hahaha. People wouldn't complain. That's a knee slapper.

Re: We will try to stop fixing bugs in PHP

#60

Post by tedunangst » Fri, Jun 22, 2012, 4:49 AM UTC

rurounijones wrote: post #4

josegonzalez wrote: post #2

Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks". For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash synta…

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…

Why would you expect PHP releases to adhere to rules that some guy threw together? Especially considering PHP has about a decade of history using the numbering scheme they do use.