From the very (very) long article you picked somewhat weird collection to defend.
> So your complaint is that when you use @ to suppress an error it... suppresses the error?
This was one bullet-point from a 7-item list. Also it didn't say that @ is bad in any way (perhaps its use is), it was there only to demonstrate error configuration which is clear by the bullets after it.
> > There is no threading support whatsoever.
> That's a good thing.
You are right that for many tasks not even thinking about threads is a good idea, but there are cases where threads are very appropriate. Having the feature wouldn't hurt, would it? (Considering how tied the php is to C)
> So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?
He explained the "so what" in the next few lines. I'll cite it for you: "If you use FALSE as an index, ..., PHP will
silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning"
Having a try statement is same as having to check for the value to be FALSE/-1/whatever, we can agree on that. But letting users write code that appears to work (yet it does not) is not a good property of a language.
> Much like Java/C/C++. PHP has array_slice() if you want it.
PHP's arrays are very different (uniform types) from those of C/C++/(Java?). So why compare them? Other than that, I agree, having slice function is enough. The author could've left this one out.
So two of your points were taken out of context, one was your opinion (two if we count your preference of if over try when checking for errors), and only two were probably justified. Rather strange choice considering you had dozens of options.
> But letting users write code that appears to work (yet it does not) is not a good property of a language.
I still don't see the point that's trying to be made here. Whether it returns -1, FALSE, or you need a try/catch, the programmer still needs to check. To successfully program in any language with an 'index of' function, a check needs to exist regardless...
In PHP, if you forget the check, and have error reporting turned off (which you should), you'd never KNOW you forgot the check, because missing it is only a logic error, whereas an exception blowing up a python script will be caught by the runtime.
> have error reporting turned off (which you should)
No, you should not. You should never have error reporting turned off. You should certainly have it set to not display errors to the client, but all errors should be sent to a log, preferably syslog, and they should be reviewed. Your code shouldn't generate any errors.
The settings related to displayed errors in the page are error_reporting and display_errors. The error logging is a totally sperate group of keys starting with log_
Yes, I know. Like I said, error_reporting on (set to E_STRICT) and display_errors off. And yes, where the error goes is a completely different question.
In production, you should have error_reporting set to something like: E_ALL & ~E_DEPRECATED
And then:
display_errors = Off
display_startup_errors = Off
track_errors = Off
html_errors = Off
ignore_repeated_errors = Off
ignore_repeated_source = Off
log_errors = On
error_log = /path/to/log/file (or syslog)
> So your complaint is that when you use @ to suppress an error it... suppresses the error?
This was one bullet-point from a 7-item list. Also it didn't say that @ is bad in any way (perhaps its use is), it was there only to demonstrate error configuration which is clear by the bullets after it.
> > There is no threading support whatsoever.
> That's a good thing.
You are right that for many tasks not even thinking about threads is a good idea, but there are cases where threads are very appropriate. Having the feature wouldn't hurt, would it? (Considering how tied the php is to C)
> So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?
He explained the "so what" in the next few lines. I'll cite it for you: "If you use FALSE as an index, ..., PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning"
Having a try statement is same as having to check for the value to be FALSE/-1/whatever, we can agree on that. But letting users write code that appears to work (yet it does not) is not a good property of a language.
> Much like Java/C/C++. PHP has array_slice() if you want it.
PHP's arrays are very different (uniform types) from those of C/C++/(Java?). So why compare them? Other than that, I agree, having slice function is enough. The author could've left this one out.
So two of your points were taken out of context, one was your opinion (two if we count your preference of if over try when checking for errors), and only two were probably justified. Rather strange choice considering you had dozens of options.