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

151–160 of 319 posts

Re: We will try to stop fixing bugs in PHP

#151

Post by Tloewald »

Xylakant wrote: post #140
gurkendoktor wrote: post #92

Earlier quoted context omitted.

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…

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.

Re: We will try to stop fixing bugs in PHP

#152

Post by RobAley »

masklinn wrote: post #137
RobAley wrote: post #131

Earlier quoted context omitted.

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 use…

With regards to consistency, aside from the fact that I don't think its easy or necessary to compare how functions deal with arguments to how syntax operators etc. deal with values, the situation prior to this change was that there was no consistency even within core functions themselves, before you even start to consider the rest of the language. This could have been resolved by changing all the other functions rather than these few, but that would have messed up a lot more userland code than this change did. I think it was the most pragmatic way of dealing with the issue.

With regards to the documentation, I'll concede that it could have been better. The previous behaviour was undefined and completely undocumented, so I think there are lessons for both "sides", 1) for the PHP team : fully document all changes, even to previously undefined/undocumented cases 2) for the users : don't implement functions in ways that are not documented (and/or santize input/validate output from functions used in such ways).

Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.

Re: We will try to stop fixing bugs in PHP

#153

Post by RobAley »

jablan wrote: post #147
RobAley wrote: post #134

Earlier quoted context omitted.

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…

I believe you are refering to strongly vs weakly typed, not statically vs dynamically typed. A strongly typed language would not try to parse the string into a number (although it would indeed accept a string, if it is dynamically typed as well).

I did indeed mean weakly typed (PHP is both dynamically and weakly typed). Haven't had my coffee yet this morning.

Re: We will try to stop fixing bugs in PHP

#154

Post by robryan »

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.

Re: We will try to stop fixing bugs in PHP

#155

Post by rapala »

masklinn wrote: post #107
LawnGnome wrote: post #101

Earlier quoted context omitted.

Even given that it was undefined behaviour to start with, it's the very first incompatible change listed at http://au2.php.net/manual/en/migration53.incompatible.php — you'd hope a professional developer would at least glance at that document when migrating a codebase to 5.3.

> Even given that it was undefined behaviour to start with On the other hand, 1. high-level languages have no reason to have UBs, especially for the trivial calling of a core function and 2. one could expect behavior in this context to be coherent with behavior in userland contexts. In PHP, using strings in a numeric context wasn't — last time I checked — considered abnormal, no matter how little sense it makes. One…

"high-level languages have no reason to have UBs, especially for the trivial calling of a core function"

What should a lisp implementation return when (car '()) is evaluated? How does a arbitrarily chosen return value differ from a undefined behavior?

Is "" -> 0 a standard conversion in PHP? I get it if we consider the groups (String, +) and (Float, +), but 0 is hardly the standard identity value.

Re: We will try to stop fixing bugs in PHP

#157

Post by methodin »

masklinn wrote: post #146
josegonzalez wrote: post #67

Earlier quoted context omitted.

Passing in an empty string to a function that states it takes float as it's argument is certainly an edge case the developer should have thought of.

The again, in PHP, interpreting strings as floats is not unusual and pretty well defined. So in PHP it's also a case the developer could have considered normal in his expectation that PHP would behave as usual (and it did, prior to 5.3, for this precise function)

Not for user-provided input. That's just a dumb thing to do in any language.

Re: We will try to stop fixing bugs in PHP

#158

Post by wccrawford »

Groxx wrote: post #105

So the options are: 1. Change thousands of lines of code (probably `sed`-able) 2. Patch PHP to re-introduce the original bug/feature 3. Downgrade PHP back to the version that had the bug/feature you were relying on Why is option 3 not considered in this thread? It was working before, and evidently they can control the version of PHP (since they can patch it). If upgrade breaks X, and you rely on X, don't upgrade. If…

3) He said they changed hosts and very few hosts offer old versions of PHP.

I don't know if that's correct, but that's what was used as an excuse.

Re: We will try to stop fixing bugs in PHP

#159

Post by masklinn »

RobAley wrote: post #152
masklinn wrote: post #137

Earlier quoted context omitted.

> 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 use…

With regards to consistency, aside from the fact that I don't think its easy or necessary to compare how functions deal with arguments to how syntax operators etc. deal with values, the situation prior to this change was that there was no consistency even within core functions themselves, before you even start to consider the rest of the language. This could have been resolved by changing all the other functions rath…

> This could have been resolved by changing all the other functions rather than these few

What "these few"? As far as I know there is no list of the functions impacted by the change, how do you define that there's just a few versus not just a few of others?

> but that would have messed up a lot more userland code than this change did.

Because ponies? Where does that arbitrary and unsupported assertion come from exactly?

> I think it was the most pragmatic way of dealing with the issue.

Why? And why was it an issue in the first place?

> The previous behaviour was undefined and completely undocumented

The previous behavior was implementation-defined (as pretty much all of PHP is) and had been stable for a decade. And as I noted above, it was also coherent with userland behavior of PHP when dealing with strings in numerical contexts.

> Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.

Which, for all intents and purposes, mean they're compatible with floats in most numeric contexts.

Re: We will try to stop fixing bugs in PHP

#160

Post by [deleted] »

xd wrote: post #127
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 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.

[deleted]
Post reply on HN