I couldn't find any way of contacting the author or leaving a comment(except on twitter) so commenting here...

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`