Posted by Chung Leong on 05/26/06 20:48

Oli Filth wrote:
> If I understand your allusion correctly, in some ways, I'd say it's the
> other way round. PHP lets you do a lot of unfunky things because the
> developers didn't like the idea of being seen to enforce "funkiness" on
> those uninitiated in the ways of funkiness, even though disciplined
> funkiness would have been for their own good! IMO, the
> static/non-static confusion and ability to add object variables
> willy-nilly are two perfect examples of this in PHP.

I guess "funk" is not a very precise term :-)

What I meant was the ability to call a non-static function statically
is highly unorthodox, but it requires extra effort to stop it. The
problem is here that the class::method() syntax is overloaded: it's
used for calling static method as well as for a non-static method to
call an overridden non-static methods in the ancestor classes. To
determine if a invocation is "legal" requires checking the context in
which it was made, which has to happen at runtime, with every call.

Whether it's worth the CPU cycles to do the check is debatable. But
since the aggregation API relies on this quirk, you can't really get
rid of it now.

> Static members mean a lot more than that just a neat way of accessing
> them separately via reflection, it's just that PHP has managed to
> confuse the issue by letting the programmer do weird things for no good
> reason. "Stricter" OO languages such as C++, Java, and C# that have the
> concept of static members enforce them as such (being compiled
> languages, they have to, obviously), and so they become a useful
> "semantic" design tool, in the same way that inheritance, "abstract",
> "final" and visibility specifiers are all useful, but completely
> unnecessary in terms of program functionality.

If you're saying that PHP isn't a good OO language, I wouldn't
disagree. In my opinion a lot of the additions in PHP 5 are just me-too
fluff. PHP can never be a strict language because of its dynamic
nature. When you can have constructs like this:

if($best_case_scenario) {

class Iraq extends Democracy {
public $army;
}

} else {

class Iraq extends Quagmire {
private $army;
}

}

The kinds of checks you can do at compile time are very limited. Doing
validation at runtime on the other hand is a drag on performance, which
is already low because the language is interpreted.

[Back to original message]