I wish bloggers would stop quoting that fractal article. At least 50% of what's written in there is totally wrong/false. Other information is terribly out of date. And even more information is merely half-truths and lack of understanding of the language. The article author clearly scanned through PHP bashing articles and took material from them verbatim; mistakes and all. I'm not going to argue that PHP is a great la…
> 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. The line you quoted is talking about ordering, not equality. > This is a good thing; JavaScript gets this wrong. It IS a good thing, but it stands out when most of the language is extremely weakly-typed…
You only need distinct operators if your language is weakly typed. If you language is strongly typed like Python, Java, or C# then there is never any conflict between addition and concatenation. VB/VB.NET is also weakly typed and has separate operators.
> So some things (objects) are passed by reference implicitly, and some (all else) are not. Yikes!
Yes, like most ever other language in existence. You know, Java, C#, Python, etc.
> Okay. Why not at top-level?
Because all code should be contained within a namespace going forward. Constants should not be defined in the top-level.
> if I write a function that can take either one value or an array of items, and you pass in a single object, I'll get a useless keyed array of its attributes.
No, it doesn't work that way. You have to explicitly cast. If you use an array type-hint you can only pass an array.
> Python and Perl are bytecode-interpreted (not positive about Ruby) and they both have rich module systems that don't require any fussing around.
PHP is also bytecode-interpreted. I'm not really sure what point you're trying to make. It's super easy to integrate code from different libraries with namespaces and autoloading.
> Why does it need to look like a function when it clearly isn't one? return and echo don't.
Because it's used an expression not a statement like return and echo. The fact that is or is not a function is insignificant; you use it the same way.
> In theory, but I've never seen any actual PHP code that uses them.
In templates you see it all the time.
> That's what exception handling is for -- unfortunately, PHP errors are an entirely separate beast from PHP exceptions.
If you convert all errors to exceptions, you could catch it. It's just an additional feature. If you handle your own errors, you can even ignore the error suppression operator if you choose.
> I said "PHP errors don't provide stack traces", and you aren't disputing that... but the runtime doesn't do it for you.
Oh, you're saying if you don't provide any of your own error handling and let it spill out the terminal -- yes, you're right -- no stack trace by default. Not that you should be doing that. If you really want that though, it can be provided by the XDebug extension.
> it's clearly not for compatibility with just PHP4
The lack of E_STRICT helps you run PHP4 code on PHP5. That's why it's not included in E_ALL. For example, I have an application that runs unmodified on PHP4 and PHP5.
> Yet I can't be sure on what parts of the language actually ARE deprecated without reading the entire manual looking for mentions of E_STRICT.
Turn on E_STRICT and it'll tell you.
> A bogus object attribute gets a warning, but a bogus class attribute is a fatal error.
Yes, one is defined and one is not.
> A string value stored in a variable can be called, but the same string value as a literal cannot.
Calling a string literal is pointless! 'test'() is test()!
> Neat, though my understanding is that this still doesn't work with fatal errors, which are shockingly common.
Fatal errors are not that common but I won't argue the point too heavily because they are a bitch. PHP developers are trying to reduce the number of fatal errors. Most IDE's will notify you of fatal error as you type.
> but that they implement half of a feature and then decide to sit down and think about the other half (while now constrained by whatever hack job they've already done).
There's nothing controversial or difficult about object type hinting. Also since PHP is meant to be typeless there is some discussion over whether scalar type hints are even necessary. Giving you something you can use right now is not a bad thing.
> Then why not use Class->foo? Why does this need two operators?
I suspect historical reasons. They really did do very different things in PHP3/PHP4.
> Regardless, it's still wildly inconsistent with the rest of the language and poorly bolted on.
How so? It's PHP object system, there is nothing for it to be inconsistent with in the rest of the language.
> How many people using PHP today came from C, exactly?
It's not about whether they came from C -- it's the fact that PHP quickly implemented access to a huge library of existing C libraries (and tracked their changes). This was a huge deal back when PHP was younger.
> Zend could have merely switched the old escape function to have the new behavior, and all existing code would have been instantly fixed, not broken.
If you've ever complained about security in PHP, you need to give that up right now. Because you just gave everyone a false sense of security.
> Either judge PHP only by the core language, or judge everything else by what you get with frameworks.
Wait, why? That's ridiculous.