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

21–30 of 319 posts

Re: We will try to stop fixing bugs in PHP

#21

Post by petercooper »

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…

It doesn't matter anyway. Semver is just a practice and not one everyone has or must sign up to, especially in its official form.

Further, you're right about Ruby 1.9's hash syntax, although in the interests of accuracy, it's more accurate to consider it an additional syntax. It certainly doesn't replace the existing one (indeed, hashes notated in the new style get returned in the old style with #inspect) and I don't believe there are plans to ever remove the standard syntax.

Re: We will try to stop fixing bugs in PHP

#22

Post by phaus »

ahi wrote: post #11
gmedel wrote: post #6

To standardize PHP code is good, let's be clear... There's a lot of "misbehaves" in PHP. And if you're not casting or checking all the time you can get a wrong result, without even knowing. At least now/then (it's an old topic) number_format WILL tell you that you're not formatting a number and that's GOOD.

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.

Re: We will try to stop fixing bugs in PHP

#24

Post by soulclap »

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://…

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.

Re: We will try to stop fixing bugs in PHP

#25

Post by petercooper »

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…

It doesn't work in the latest 1.9 either. It was a bizarre syntax that hardly anyone used from my experience (I've been a library-oriented Rubyist for several years and never saw it in production code.)

However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..

Re: We will try to stop fixing bugs in PHP

#26

Post by justindocanto »

"This is going to cause us MONTHS (to fix)". Whether he is right or wrong, you cannot say he's not over-exaggerating and being a pain in the ass. Also, expecting "" to == 0, when it's easier and proper to enter 0 just doesnt make sense. That's like saying "i expected your software to make up for me not using it correctly". Sass or not from the guy who wrote PHP, this guy is just a pain in the ass and his complaint is ridiculous.

ADDITION: As the creator stated, it's been issuing warnings for some time now and was changed LAST YEAR. there's just no foundation to this complaint.

Re: We will try to stop fixing bugs in PHP

#28

Post by steve8918 »

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

Re: We will try to stop fixing bugs in PHP

#29

Post by blantonl »

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…

this is a classic example of "you mess with the bull, you get the horns."

Re: We will try to stop fixing bugs in PHP

#30

Post by reitzensteinm »

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.
Post reply on HN