These are things in PHP which make me sad

It may have been possible to do that when the language was originally designed but PHP has taking the long road to getting real OOP. PHP3 had objects but no inheritance; they were really just structs with functions. PHP4 added a lot more ability but, for reasons of compatibility, left a few things unchanged that should have been changed. PHP5 fixed most of those remaining issues and continues to add more features with every release. PHP wasn't designed all at once and things were added as developers demanded them. It was just supposed to be a procedural languages like ASP/VBScript but as a mix of C and Perl; all this object oriented stuff wasn't in the original plan. It now has namespaces and exceptions and all kinds of things that nobody imagined it would ever have. So they can't use one operator for all because each operation compiles down to something different (each from a different time) and that difference needs to be known at compile time without the benefit of knowing what the symbols resolve to.

> Other people -- who probably use and enjoy other languages -- raise issues with PHP that point at poor design.

This is a poor argument. I use and enjoy many other languages. In fact, I'm hardly doing any PHP development right now but I've got half-completed side project I'd like to finish. There's no argument: PHP has a poor design. But if you put things in the context of history, there is reason for that poor design.

> Then you respond with a rationale for why the well-designed thing couldn't be done.

I'm just stating the facts. In this case, it's not like they're going out of the way to be difficult but they have to work with what they have. If you have a time machine we could solve this once and for all.

> that doesn't make it a good decision in retrospect.

Of course, but hindsight is always 20/20. Perhaps Python should have had unicode to start with and should have never made print a statement instead of a function. Perhaps templates were not the best way to add generics to C++. See, we can play this game all night.

> Do you mean that other languages can be compiled to PHP more easily? Because I have never heard this rationalization before.

Yes. That rationalization was one of the reasons for adding it although more in the context of targeting parser generators (like lexx and yacc) to PHP. Even Dijkstra didn't think that goto should been banished from all languages forever.

Not suggesting that you don't use good languages (unless you use and enjoy PHP). Just saying where other people are coming from.

> Of course, but hindsight is always 20/20. Perhaps Python should have had unicode to start with and should have never made print a statement instead of a function. Perhaps templates were not the best way to add generics to C++. See, we can play this game all night.

The only response I really have to this is that, when some other language teams realize they need to change, they have a better process for setting the future direction of their language.

Much of the fail you describe as being the result of accumulation is really, in my mind, a failure to set or predict the direction of the language.

How is it strange? When you declare your iteration variable, it unsets any existing definition of that variable if there is one, before it inserts the new variable. Why would anyone enter a loop and expect the iteration variable to have a value defined outside the loop?

Moreover, even if someone can find a reason why -- why make define the language around a need to support such badly designed programs.

> I'm afraid the behavior it has is the expected behavior.

Fine. s/expected/intuitive/g

> The problem isn't the language in this case.

Agreed. It's the people who designed it.

> These problems just aren't that bad.

This is my point: the individual issues are all workable. The real problem is that the language is maintained by people who have no idea how to design a language, frankly.

Before I start I must say it would have been nice if a proper set-up was done for the screenshots, white-marks(censor) on the images just distract from the point you're trying to make.

I personally disagree with some of these points...

on point #2

> Class definitions should not result in the execution of any code, period. Whether or not that warrants a syntax error is up for debate, but that code does not look very constant from here and is some-sort-of an error in my view.

on point #37

> `"a" . "b"` doesn't make sense as useful code... `__DIR__ . "/file"` could be useful, but as already argued, it's not a constant and therefore should not be getting any special treatment. If it did, then I'd consider it a bug - as it leads to more inconsistency, ambiguity and bugs.

on point #8

> I guess we could argue this one all day. Personally I don't think it should ever return true as an object is not an array and vice versa. likewise, property_exists should not work on an array(). It's documented that array_key_exists no longer works with objects as-of php 5.3, whether or not id did before that I don't know. I can't really think of a use-case for that function when you have isset().

on point #18

> I think this one can go either way, for what purpose is a static variable useful on an object instance?

on point #33

> I feel so strongly about this one that I think it should be removed entirely. Unlike the other points I don't think this one is open for discussion in any case. I simply can't understand why this code should ever be valid. It completely goes against the point of OO and information hiding. You'll take care to note that it works as expected if you make it protected as opposed to private. That's the idea of having private and protected. Furthermore, you say pretty much the same thing. In the code, it does override it - no question. Call `$obj->b();` and see what happens. The reason you think it doesn't work is because `a()` unless overriden, is comes from `class super` and is therefore tied to `class super`. In other words, it's never supposed to work...

on point #41

> Yeah... I don't get it.

on point #28

> I'm pretty sure empty() is not a function which renders the rest of the point moot. Inconsistent behaviour? I think so. Again with the function chaining and need for a temporary variable. Provide snippets if you can, please. Otherwise it's hard to understand things from your POV.

The whole bugs section is moot - they're bugs and are therefore implementation dependent - i.e has nothing to with the language.

on point #11

> This isn't so-much a disagreement so I'll use it to ask what's up with the numbering... Anyway I don't understand the part about memory use - I wouldn't be surprised if the memory-use on the main page increased more than 30KiB simply by including that point. So in theory, leaving it out would in-fact be saving memory :p

on point #14

> I think it's a good thing, in the same vein on throwing in destructors. It's not funny in C++ and it damn sure ain't funny in PHP either.

on point #38

> I think that's a good thing - if you know you can't catch a fatal error then if forces you to write better code.

on point #20

> I must admit that I've never seen use of `\e` for this - only `\033` and `\x1b`.

on point #35

> It shouldn't - that's like setting a bear trap in from of your doorway and then go out to get drunk so you can come back and step on it.

on point #26

> Maybe it makes sense to me coming from C/C++ and GCC but E_STRICT doesn't report errors and therefore doesn't belong in E_ALL. Contrast GCC's `-Wall` and `-Wall -Wextra`