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

131–140 of 319 posts

Re: We will try to stop fixing bugs in PHP

#131

Post by RobAley »

masklinn wrote: post #106
earl wrote: post #87

Earlier quoted context omitted.

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.

As you note, one of the problems most cited with PHP is core language functions behaving in a non-coherent/non-consistent manor. This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. It was documented, done in a major release, and done alongside a number of other (well publicised) breaking changes. Not everyone is going to be happy when things change, but I think this was a sensible development decision for the PHP team.

Re: We will try to stop fixing bugs in PHP

#132

Post by RobAley »

pippy wrote: post #54

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

A lot of the time, it's developers who don't use PHP who complain its not standardised, and developers who do use PHP who complain when it does change! To be contrary, I'm a PHP developer who likes the on-going standardisation, but didn't really find it too big a problem the existing way. YMMV.

Re: We will try to stop fixing bugs in PHP

#133

Post by Kabacaru »

Groxx wrote: post #115
sold wrote: post #114

Earlier quoted context omitted.

Problem 1: The old versions do not get security patches. For example, entering the number 2.2250738585072011e-308 hangs the interpreter in old versions, as far as I know this is unpatched in PHP Problem 2: You are delaying the unevitable; it's nice to use new features of the language, having to code in old versions is a pain for developers. Small continuous upgrades are easier to handle than rare gigantic ones.

Small continuous upgrades without ever changing your code is the same cost as a gigantic one without ever changing your code - they either work, or they don't, in variously subtle or spectacular ways. The tipping point lies at some changeset, you just need to hit it. You upgrade, you may need to change things. It's just a fact of life. Or, you pick a library / language / framework / everything that guarantees 100% ba…

This is why having a good suite of unit tests is so important.

Re: We will try to stop fixing bugs in PHP

#134

Post by RobAley »

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?)

PHP is a dynamically typed language, so although it expects a number, it will accept a string as it will try and parse that string into a number (e.g. you could pass it the string "2.23232" and it will work in the same way as if you pass it 2.23232 as a float). In this particular case, as the empty string can't be parsed into a number, it does indeed throw a PHP warning and treats it as a null input. My understanding is that it used to return 0 and that was considered a bug by some (although others, including the author of the function, decided that as the return type was a number it should ALWAYS return a number). The change that is under "dispute" in this case is that it has indeed been changed to return null, which is what most people now agree is the best way, and is consistent with other PHP functions.

Re: We will try to stop fixing bugs in PHP

#135

Post by lmm »

aniket_ray wrote: post #98
kyberias wrote: post #96

People have been wondering "what would Linus have said?" I'm pretty sure he wouldn't have broken the existing (undocumented) behavior in the first place "because it breaks applications and the one and only reason for kernel is to allow applications to run". But then again, PHP is not a kernel. :)

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.

Re: We will try to stop fixing bugs in PHP

#136

Post by pacifika »

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.

Re: We will try to stop fixing bugs in PHP

#137

Post by masklinn »

RobAley wrote: post #131
masklinn wrote: post #106

Earlier quoted context omitted.

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.

As you note, one of the problems most cited with PHP is core language functions behaving in a non-coherent/non-consistent manor. This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. It was documented, done in a major release, and done alongside a number of other (well publicised) breaking changes. Not everyone is going to be ha…

> This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently.

Well technically I believe it was done to unify argument parsing, but so far so good.

> to make it behave more coherently/consistently.

except this made all argument parsing (and especially this function) less coherent and consistent with PHP-the-actual-language: in PHP userland code, a string in a numeric concept will be implicitly converted to a number (to 0 if it is not prefixed by digits). This function used to behave coherently with PHP itself, as a language. Now it doesn't anymore. So all built-ins behave one way, the language itself behaves in the opposite way.

> It was documented

Not really, there was a note indicating plenty of shit broke (and it was ambiguous, the note says things about passing in incompatible parameters, but as far as PHP-the-language goes strings are compatible with floats), not listing functions which broke and in which manner.

Re: We will try to stop fixing bugs in PHP

#138

Post by alkavan »

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.

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

#139

Post by ivix »

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.

Of course, in a more sane language, it would throw an exception, rather than silently returning a wrong value.

Re: We will try to stop fixing bugs in PHP

#140

Post by Xylakant »

gurkendoktor wrote: post #92
josegonzalez wrote: post #34

Earlier quoted context omitted.

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.

I just wanted to reinforce that Ruby and PHP are equally unstable languages. Most changes in my list aren't bugs at all, just obscure design decisions. Even the new Hash literals are likely complicit in breaking the "when X:" syntax that I'd heavily relied on. The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.

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 byte streams and the encoding didn't matter.

Changing the way require works fixed a potential attack against ruby scripts. Effectively the only thing that was changed was that from that point on the working directory was not included in the loadpath any more. Calling `ruby -I . ` reverts to the previous behavior. Backporting require_relative is not a sensible decision, 1.8 has reached EOL. If you need to write code that compatible to both ruby versions, just don't use it. It's nothing but a convenience method (in fact, most libraries just use a proper LOAD_PATH setup and don't use it). Since 1.9.2 was the first stable release of the 1.9. branch it's fair enough at that point.

Breaking the extension API between 1.8 and 1.9 is fair enough as well since Ruby 1.9 is a new major release. Ruby's versioning works different than PHPs. A minor PHP release (5.3.1 -> 5.3.2) would be a patch release in ruby (1.9.3-p0 -> 1.9.3-p125). Breaking changes are required at some point. 1.9 added more breaking changes, such as String not being enumerable any more etc. Most of those were required to add encoding support, which was the big and important feature added at that time.

All in all I must say that the only large-scale breakage of existing code I've witnessed in the ruby world was the 1.8 -> 1.9 transition.

Post reply on HN