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

141–150 of 319 posts

Re: We will try to stop fixing bugs in PHP

#141

Post by regularfry »

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…

Neither Ruby nor, as far as I know, PHP follow semver. Historically all bets have been off when it comes to breaking changes on "minor" releases.

Re: We will try to stop fixing bugs in PHP

#142

Post by mogui »

jbm wrote: post #129
xd wrote: post #127

Earlier quoted context omitted.

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

Don't sweat it. Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress). I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around w…

words full of wisdom, sir

Re: We will try to stop fixing bugs in PHP

#143

Post by alkavan »

JaggedJax wrote: post #65
Evbn wrote: post #31

Earlier quoted context omitted.

I guarantee that security guidelines were not involved in any decision about which version of PHP to use in a project. All PHP code is security tainted and needs protection at the underlying data service layer.

I would almost guarantee security guidelines were the reason. He states they are dealing with tax data, and I would bet they handle some credit card data as well. If they even touch credit card data they have to be PCI compliant ( http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu... ) which requires specific versions of PHP.

Where does it say in this page a specific version of PHP ? I searched for "PHP" and did not find anything.

Re: We will try to stop fixing bugs in PHP

#144

Post by Beltiras »

jbm wrote: post #129
xd wrote: post #127

Earlier quoted context omitted.

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

Don't sweat it. Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress). I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around w…

Which is why you should use Python, not PHP ;) (Penis submitted for measurement)

Re: We will try to stop fixing bugs in PHP

#145

Post by stan_rogers »

Evbn wrote: post #33
jconley wrote: post #17

Regardless of merit on either side, the attitude presented by the creator of PHP in this post makes PHP and open source in general look bad. Seriously? I still can't believe that's how the situation was handled. EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take ju…

Why is one person working on one ancient project the face of open source?

"One person" isn't. Rasmus isn't the only contributor to PHP, but it is his baby (originally released as his Personal Home Page Tools in the Long, Long Ago). That other people have worked on and contributed to PHP over the years doesn't change the fact that he's the creator of PHP.

Re: We will try to stop fixing bugs in PHP

#146

Post by masklinn »

josegonzalez wrote: post #67
piggity wrote: post #56

Earlier quoted context omitted.

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.

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)

Re: We will try to stop fixing bugs in PHP

#147

Post by jablan »

RobAley wrote: post #134
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…

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

Re: We will try to stop fixing bugs in PHP

#148

Post by masklinn »

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

> First of all, why does the function even accept strings?

Why not?

> There should be some eception happening.

PHP's built-in functions do not ever throw exceptions.

> Second, why does it return 0, i could understand NULL but not 0

Well it doesn't anymore, but it used to, and that kind-of made sense in the context of the language being PHP: in PHP (userland), when using a string in a numeric context that string will automatically be converted to a number:

    > php -r 'print (1 + "3") . "\n";'
    4
when the string can not be parsed to a number (meaning it is not prefixed by something which looks like a number), it's just converted to `0`:

    > php -r 'print (1 + "whelp") . "\n";'
    1
And I expect that is the former behavior of the function: it coerced whatever it got to a number, so an empty or non-numeric string would get converted to the float 0.0, which would then get formatted as usual.
Post reply on HN