Second time I've seen that link in this same article. I am absolutely sick of seeing it - there's a *few* errors in it. For example:

Operators are very fragile in the parser; foo()[0] and foo()->method() are both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t find mention of a fix for the latter.

The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works?

Objects compare as greater than anything else except other objects, which they are neither less than nor greater than.

Strict-equals on objects compares the references; but regular equals compares the contents of the objects. Two objects compare equal if the contain exactly the same fields and values. Seems pretty reasonable to me.

• is always addition, and . is always concatenation.

This is a good thing; JavaScript gets this wrong.

There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.

Variables that don't exist issue a notice. You can deal with that just like any other error.

Global variables need a global declaration before they can be used.

Actually there is also the $GLOBALS array for this. I'll agree that's not much a solution. Globals should just not be used; if you want to use static class variables, it's a much better choice with a sane syntax.

there’s no pass-by-object identity like in Python.

I'm not sure if I understand this but all objects are passed-by-reference in PHP (since 5) and PHP references act appropriately when used as function parameters, etc.

A reference can be taken to a key that doesn’t exist within an undefined variable (which becomes an array). Using a non-existent array normally issues a notice, but this does not.

An attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly.

Constants are defined by a function call taking a string; before that, they don’t exist.

You can declare constants in classes and namespaces with the const keyword.

There’s an (array) operator for casting to array. Given that PHP has no other structure type, I don’t know why this exists.

You can cast scalars to single element arrays and objects to arrays with the same structure. Both are actually very useful.

include() and friends are basically C’s #include: they dump another source file into yours. There is no module system, even for PHP code.

PHP is interpreted -- namespaces and autoloaders are PHP's module system.

Appending to an array is done with $foo[] = $bar

This is a good thing.

empty($var) is so extremely not-a-function that anything but a variable,

Empty is equivalent to the not operator but will also work on undefined variables -- that's why it requires a variable.

There’s redundant syntax for blocks: if (...): ... endif;, etc.

Useful inside of templates where matching { } is much more difficult.

PHP’s one unique operator is @ (actually borrowed from DOS), which silences errors.

Sometimes you don't care if a function succeeds; like with the unlink() function which will raise an error if the file you're trying to delete doesn't exist.

PHP errors don’t provide stack traces.

Not true. Debug_backtrace() will give you a stack trace in an error handler.

Most error handling is in the form of printing a line to a server log nobody reads and carrying on.

Assuming, of course, the programmer doesn't do anything to handle errors.

E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does.

E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it will "warn you about code usage which is deprecated or which may not be future-proof." -- quote from the manual.

E_ALL includes all error categories—except E_STRICT.

Unfortunate naming here -- E_ALL is from PHP4 and prior and E_STRICT is all about PHP5. Including it in E_ALL would break PHP4 scripts running on PHP5.

Weirdly inconsistent about what’s allowed and what isn’t.

This author is confused why syntax errors would be parse errors but logic errors are not.

PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.

This is sort of true; PHP errors and exceptions exist in different universes but it's easy to unify them and PHP even provides a built-in exception ErrorException to do so. You can turn every PHP error into an exception with 4 lines of code complete with stack traces. You could even turn exceptions into errors but I wouldn't recommend that. PHP supports both procedural and OO programming styles -- this is not a bad thing.

There is no finally construct

C++ also doesn't have a finally construct. But C++ and PHP support RAII -- class destructors run when the stack is unwound so you can do your cleanup. Finally would be a welcome addition to both languages.

function foo() { return new __stdClass(); } leaks memory. The garbage collector can only collect garbage that has a name.

PHP is reference counted with a cycle-detecting GC. That would not leak memory.

Function arguments can have “type hints”, which are basically just static typing. But you can’t require that an argument be an int or string or object or other “core” type

This is true, but it's an ongoing discussion on how to correctly handle scalar type hints. For all the discussion about how PHP isn't designed the author takes issue with the thing they're taking their time on.

Closures require explicitly naming every variable to be closed-over. Why can’t the interpreter figure this out?

Because of the dynamic abilities of PHP, there is simply no way for the interpreter to ever figure out the variable to close over. The solution is actually a rather simple.

clone is an operator?!

Of course!

Object attributes are $obj->foo, but class attributes are $obj::foo. I’m not aware of another language that does this or how it’s useful.

C++ does it. $obj::foo doesn't make any sense, if you're accessing class attributes then you use the class name Class::foo.

Also, an instance method can still be called statically (Class::method()). If done so from another method, this is treated like a regular method call on the current $this. I think.

Only static methods can be called statically. The other calling methods statically is similar to C++ ... you can call parent class methods explicitly by name by-passing any overriding.

new, private, public, protected, static, etc. Trying to win over Java developers? I’m aware this is more personal taste, but I don’t know why this stuff is necessary in a dynamic language

This is personal taste not a valid critique.

Subclasses cannot override private methods.

That is the definition of private methods!

There is no method you can call on a class to allocate memory and create an object.

You can use reflection to create an object without calling the constructor.

Static variables inside instance methods are global; they share the same value across all instances of the class

This is the definition of a static property!

Yet a massive portion of the standard library is still very thin wrappers around C APIs

That is, in fact, the point. PHP is supposed to be a thin scripting language layer over C. It's expanded beyond that. Many of the poor naming conventions are not because of PHP but rather are the exact API of the underlying C library.

Warts like mysql_real_escape_string, even though it has the same arguments as the broken mysql_escape_string, just because it’s part of the MySQL C API.

Both the C API and PHP have both these functions for backwards compatibility reasons. This entire API is pretty much depreciated with both the mysqli library and PDO replacing it.

Using multiple MySQL connections apparently requires passing a connection handle on every function call.

Yes, exactly. That's the only way multiple connections could possibly work.

PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it.

Unless you use a free code cache like APC. It will eventually be built in. Most people don't need it.

For quite a long time, PHP errors went to the client by default

If you don't handle your errors, they go somewhere.

Missing features

Most of these are provided by frameworks just as they are in Python, Ruby, C#, etc.

Insecure-by-default

Most of these things are now removed from the language after being depreciated for years.

I too could spend the time writing several paragraphs explaining in detail why this article is incorrect and the misunderstandings and misapprehensions the author is under. I'm fed up of seeing this propaganda going unargued.

Thankfully, someone has already detailed this for me:

Just a few errrors in the article:

Operators are very fragile in the parser; foo()[0] and foo()->method() are both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t find mention of a fix for the latter.

The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works?

Objects compare as greater than anything else except other objects, which they are neither less than nor greater than.

Strict-equals on objects compares the references; but regular equals compares the contents of the objects. Two objects compare equal if the contain exactly the same fields and values. Seems pretty reasonable to me.

• is always addition, and . is always concatenation.

This is a good thing; JavaScript gets this wrong.

There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.

Variables that don't exist issue a notice. You can deal with that just like any other error.

Global variables need a global declaration before they can be used.

Actually there is also the $GLOBALS array for this. I'll agree that's not much a solution. Globals should just not be used; if you want to use static class variables, it's a much better choice with a sane syntax.

there’s no pass-by-object identity like in Python.

I'm not sure if I understand this but all objects are passed-by-reference in PHP (since 5) and PHP references act appropriately when used as function parameters, etc.

A reference can be taken to a key that doesn’t exist within an undefined variable (which becomes an array). Using a non-existent array normally issues a notice, but this does not.

An attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly.

Constants are defined by a function call taking a string; before that, they don’t exist.

You can declare constants in classes and namespaces with the const keyword.

There’s an (array) operator for casting to array. Given that PHP has no other structure type, I don’t know why this exists.

You can cast scalars to single element arrays and objects to arrays with the same structure. Both are actually very useful.

include() and friends are basically C’s #include: they dump another source file into yours. There is no module system, even for PHP code.

PHP is interpreted -- namespaces and autoloaders are PHP's module system.

Appending to an array is done with $foo[] = $bar

This is a good thing.

empty($var) is so extremely not-a-function that anything but a variable,

Empty is equivalent to the not operator but will also work on undefined variables -- that's why it requires a variable.

There’s redundant syntax for blocks: if (...): ... endif;, etc.

Useful inside of templates where matching { } is much more difficult.

PHP’s one unique operator is @ (actually borrowed from DOS), which silences errors.

Sometimes you don't care if a function succeeds; like with the unlink() function which will raise an error if the file you're trying to delete doesn't exist.

PHP errors don’t provide stack traces.

Not true. Debug_backtrace() will give you a stack trace in an error handler.

Most error handling is in the form of printing a line to a server log nobody reads and carrying on.

Assuming, of course, the programmer doesn't do anything to handle errors.

E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does.

E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it will "warn you about code usage which is deprecated or which may not be future-proof." -- quote from the manual.

E_ALL includes all error categories—except E_STRICT.

Unfortunate naming here -- E_ALL is from PHP4 and prior and E_STRICT is all about PHP5. Including it in E_ALL would break PHP4 scripts running on PHP5.

Weirdly inconsistent about what’s allowed and what isn’t.

This author is confused why syntax errors would be parse errors but logic errors are not.

PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.

This is sort of true; PHP errors and exceptions exist in different universes but it's easy to unify them and PHP even provides a built-in exception ErrorException to do so. You can turn every PHP error into an exception with 4 lines of code complete with stack traces. You could even turn exceptions into errors but I wouldn't recommend that. PHP supports both procedural and OO programming styles -- this is not a bad thing.

There is no finally construct

C++ also doesn't have a finally construct. But C++ and PHP support RAII -- class destructors run when the stack is unwound so you can do your cleanup. Finally would be a welcome addition to both languages.

function foo() { return new __stdClass(); } leaks memory. The garbage collector can only collect garbage that has a name.

PHP is reference counted with a cycle-detecting GC. That would not leak memory.

Function arguments can have “type hints”, which are basically just static typing. But you can’t require that an argument be an int or string or object or other “core” type

This is true, but it's an ongoing discussion on how to correctly handle scalar type hints. For all the discussion about how PHP isn't designed the author takes issue with the thing they're taking their time on.

Closures require explicitly naming every variable to be closed-over. Why can’t the interpreter figure this out?

Because of the dynamic abilities of PHP, there is simply no way for the interpreter to ever figure out the variable to close over. The solution is actually a rather simple.

clone is an operator?!

Of course!

Object attributes are $obj->foo, but class attributes are $obj::foo. I’m not aware of another language that does this or how it’s useful.

C++ does it. $obj::foo doesn't make any sense, if you're accessing class attributes then you use the class name Class::foo.

Also, an instance method can still be called statically (Class::method()). If done so from another method, this is treated like a regular method call on the current $this. I think.

Only static methods can be called statically. The other calling methods statically is similar to C++ ... you can call parent class methods explicitly by name by-passing any overriding.

new, private, public, protected, static, etc. Trying to win over Java developers? I’m aware this is more personal taste, but I don’t know why this stuff is necessary in a dynamic language

This is personal taste not a valid critique.

Subclasses cannot override private methods.

That is the definition of private methods!

There is no method you can call on a class to allocate memory and create an object.

You can use reflection to create an object without calling the constructor.

Static variables inside instance methods are global; they share the same value across all instances of the class

This is the definition of a static property!

Yet a massive portion of the standard library is still very thin wrappers around C APIs

That is, in fact, the point. PHP is supposed to be a thin scripting language layer over C. It's expanded beyond that. Many of the poor naming conventions are not because of PHP but rather are the exact API of the underlying C library.

Warts like mysql_real_escape_string, even though it has the same arguments as the broken mysql_escape_string, just because it’s part of the MySQL C API.

Both the C API and PHP have both these functions for backwards compatibility reasons. This entire API is pretty much depreciated with both the mysqli library and PDO replacing it.

Using multiple MySQL connections apparently requires passing a connection handle on every function call.

Yes, exactly. That's the only way multiple connections could possibly work.

PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it.

Unless you use a free code cache like APC. It will eventually be built in. Most people don't need it.

For quite a long time, PHP errors went to the client by default

If you don't handle your errors, they go somewhere.

Missing features

Most of these are provided by frameworks just as they are in Python, Ruby, C#, etc.

Insecure-by-default

Most of these things are now removed from the language after being depreciated for years.

When they tried to bury him, apparently the coffin has broken - the lid has come off,
In his honour it has been sellotaped back on.

Do you think they've tried turning his batteries round and smacking him against the coffee table?

It's not just Amazon - Google and eBay are doing exactly the same thing.

Google is also infested with sites that contain malware. There are people who use it to spread viruses and malware. It makes sense too - it's quite easy method to infect peoples computers.

It contains a lot more viruses than TPB ever could.

Should Google be blocked too?

They'll delete him? That's murder!

So your best reason against cellphone jammers is that there "might be someone near a bus who needs to make a call"?

I'm not singling you out personally here, but you've entirely missed the point and just replied blindly without reading the parent comments.
I said I personally think jammers are a terrible idea under any circumstance, but some of the scenarios people are using for justification against them are insane. There's far better arguments against them.

There's plenty of reasons to ban them; but no-one seems to be following the thread and instead arguing that they should be banned just because
"someone might need to make a 911 call while someone drives past with a jammer switched on who might be a part time vet who needs to visit a Corgi with a chest infection"?

I don't think that's a very substantial argument.

Thank you for being the only person who replied who got this! It seems very few people read the thread anymore.

I personally think jammers are a terrible idea under any circumstance, but some of the scenarios people are using for justification against them are insane.
There's plenty of reasons to ban them; but because "someone might need to make a 911 call on a bus"?... bloody hell.

Why would anyone be making a private 911 call on a bus? Especially without any of the other passengers knowing?

I mean, I'm not agreeing with this; but that's a ridiculous claim under this scenario.

Apparently you're new here too; like I replied to the other person, this means nothing. All distractions are dangerous; but how dangerous are they? The GP asked about "Risk Change", not "Is this 'dangerous'?"; since that has such an obvious answer.

Simply remembering that I replied this way to your message may be a distraction to your driving tomorrow. Does that mean I'm a danger to your driving, and that you should be fined £50 for thinking of me?
Or should this only apply to smoking? Or to eating? Or for having passengers? Or singing to yourself? Do you see my point?

Everything is a distraction at some degree, even thinking about this message tomorrow while you're driving could distract you.

Yes or no is meaningless, and 100% is concentration is almost certainly unachievable. Stop being silly and give me numbers, dammit.

How about for non-smart phone users?

Does it help if you don't have to hold the phone with both hands to type?

It's not wealth or having a Prius. It's smugness.

My Doctor said this too; that I should do something once a day that makes me out of breath, so I've taken up smoking.


(with thanks to Jo Brand)