Live data from Hacker News

We will try to stop fixing bugs in PHP

bugs.php.net

121–130 of 319 posts

Re: We will try to stop fixing bugs in PHP

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

Re: We will try to stop fixing bugs in PHP

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

If it requires specific versions of PHP, I would hope that doesn't include a self-patched build that deliberately masks erroneous input data by treating NULL as 0

The moment you run a patched build, you're IMHO not running the officially sanctioned version any more.

Re: We will try to stop fixing bugs in PHP

#123
I have to agree with the bug submitter in concept, if not in attitude. PHP is a dynamically typed language. As such, methods should expect surprises about the types of data received. Seriously, I've had PHP treat the same input as a string one time, an interface another, it's like it uses whatever is convenient at the time. If you neeeeed that data to be an int, cast it as an int, don't punish the user because type system chose a different type this time.

Additionally, and more to the point, in PHP 0 == "" == null == false, so it shouldn't be unreasonable to expect them to be treated as equivalent. It's also a nice thing when a method can always be trusted to return the same type, or these types of issues can end up cascading.

In any case, 'should' and 'nice' things are hard to rely on in PHP, that's why you should always have the docs open and read everything when writing PHP, making even basic assumptions about a method being well behaved will likely screw you over. :)

Re: We will try to stop fixing bugs in PHP

#124
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?

Are you somehow under the impression that developers are the Borg? Different developers can have different opinions on what PHP should be.

Re: We will try to stop fixing bugs in PHP

#125
post #81

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…

if you can't do that trivial change on some convulated release system... You don't change php version either. Unless you are addressing security changes. I think its very professional to not bump versions just for the sake of it. release notes exist for a reason.

As far as I understood, the release notes were not very explicit or complete (the list of impacted functions were missing) on this issue.

Recently I have encountered a problem with redhat migration: /usr/bin/X11/xwd was "moved" to /usr/bin/xwd. I have not found anything in the release note.

It is not enough to ask people to read the release notes, these release notes should be complete and usable.

Re: We will try to stop fixing bugs in PHP

#127

Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

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.

Re: We will try to stop fixing bugs in PHP

#128

Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

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…

"This bug report highlights the problems you run into if you use it for serious work"

Why? Because they fix bugs that break backwards compatibility? What's your point? That to do "serious work" you need a language that never changes or that you need a language that gets everything right the first time?

Of course can do whatever you want in PHP, you just need to account for its faults and shortcomings. If you cant do that, no language is going to save you.

Re: We will try to stop fixing bugs in PHP

#129
post #127

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.

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 with servers in order to perform my job.

The critiques of the language aren't baseless, but plenty of large startups manage to do just fine with PHP.

TLDR: Languages are meaningless penis measuring contests of the IT world. If you will ship faster and better with language X, go ahead and use it.

Re: We will try to stop fixing bugs in PHP

#130

Love this snippet: > > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com > Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net

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

So do Facebook.

Post reply on HN