Please enlighten me! I'm interested in correctness.
The "non-programmers" remark refers to a quote from the PHP 2.0 documentation. I tried to minimize the editorializing.
The "non-programmers" remark refers to a quote from the PHP 2.0 documentation. I tried to minimize the editorializing.
The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works?
> == is useless.
Actually, it's not useless. It does have a few stupid edge-cases and I will admit that. But in most common cases actually does the right thing and the truth table isn't too different from JavaScript.
> 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.
I just discovered this recently and it's a great feature. Obviously an attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly. This can be very handy.
> 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; I'm not sure what kind of module system you think it needs. Most projects don't use include() directly and instead have autoloaders.
> Appending to an array is done with $foo[] = $bar
You state this like it's a bad 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.
Yup. I find it very useful on 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. How is this different from any other language?
> 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.
Then you go on to be 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.
> 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. You could that 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.
I am unsure where you got this idea from. 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 you take 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 this out. I thought the solution provides was actually a rather simple way of resolving the problem.
> clone is an operator?!
Of course! Why wouldn't it be.
> 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.
> 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. A non-static call can be made that way and passed on $this. This can be useful and isn't terribly confusing -- similar syntax as calling parent methods.
> 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
PHP classes are basically statically compiled. The class code isn't run, it's compiled into byte code before the execution of the script. This is similar to if you just ran the Java compiler on Java code before each run. It's a design decision that has it's pros and cons.
> 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
Again this is the definition of a static variable in any language!
> 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. Of course, this entire API is pretty much depreciated with both the mysqli library and PDO.
> Using multiple MySQL connections apparently requires passing a connection handle on every function call.
How would you expect that to work?
> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it.
Unless you use a code cache like APC. It will eventually be built in but an easily added option. I suspect most people, however, 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. Why would PHP be any different.
> Insecure-by-default
Only if you're using an ancient version. Some of these things are now removed from the language after being depreciated for years.
I'm actually getting a bit tired so I'm going to bed. I didn't comment on everything in the article: some of them are right. But some of them are just different. Some of them have even been replaced by newer methods of doing things.
PHP has been around for a long time -- I remember when I switched from Classic ASP (yes, VBScript) to PHP and it was a dream. Many of things to complain about now, like the kitchen-sink standard library, were a godsend. It also evolved very quickly during that time and I suspect if it hadn't then it wouldn't have caught on enough to be bitched about now.
For the most part you've defended PHP's behavior as design decisions or offered workarounds. Workarounds just demonstrate that the language is Turing-complete. Design decisions are only okay if they actually make a useful tradeoff; these generally do not.
I can give you individual responses if you really want, but I suspect you won't be swayed no matter what I say. I will comment:
PHP doesn't need a module system? What? Once your program consists of more than two files, you're going to want to import stuff from one into the other in a structured manner.
PHP has a module system: Namespaces and the class autoloader.
But a few things are weird to you but not some objective view of weird. Many of your points I didn't comment on are not unique to PHP at all (such as octal numbers)
> For the most part you've defended PHP's behavior as design decisions or offered workarounds.
You could say that unifying PHP error codes and exceptions is a "workaround" but the language provides specific support for it (The ErrorException class) so it's pretty much a standard pattern. The end developer has the choice of development style.
> PHP doesn't need a module system? What?
I have projects with thousands of files -- as someone else said, Namespaces and Autoloaders covers this.
Also you should check out what Alan Storm has to say about this: http://alanstorm.com/python_imports_for_php_developers
Mr. Storm is a crackerjack PHP developer: perhaps you will listen to him.
PHP does things differently; you don't import things before you use them -- PHP loads modules/classes as necessary when they're used. If you don't use a class, it's not loaded.
Other features of PHP make things like "import *" impossible (or at least very expensive) but at the same time it's also much less necessary.