Re: Declaration of Bar::__construct() must be compatible

Ferdinand Beyer wrote:

IMO we are trying to force a strict programming here that is incompatible with PHP's loose character.

Yeah, I absolutely agree with that. The more I think about it the more it also seems like this change is going to break a *lot* of PHP code out there. Especially the example that Timm and Ferdinand give w/ constructors. I'm already frustrated that in my JDBC-like abstraction layer my PreparedStatement class cannot extend Statement, because PreparedStatement has an executeQuery() method that does not take any parameters, while the more generic Statement::executeQuery($sql) needs the query passed to it. In every other way PrepareStatement is a subclass. I guess basically I think that if PHP is not going to support overloading, then it needs to allow for a looser interpretation of the isA contract. In that case I'm also using interfaces, and I realize that interfaces require the inheritance to be a bit more strict -- and I'm at peace with that :) (though I really think interfaces should be allowed to override too, just to be consistent in PHP). This especially bothers me, I suppose, because I've been doing a lot of work creating PHP5 versions of a few Java apps (Torque, Ant). This change will break a great deal of my code, and I can only imagine that it will break many other existing PHP4 classes out there. I don't want to have to turn compatibility mode on for code that I wrote for PHP5 (!)

The following example for instance is very common in Java AVT programming: <?php class Window {

    function __construct($title)
    {
    }

} class MyApplicationWindow extends Window {

    const VERSION = "1.1";

    function __construct()
    {
        parent::__construct("My Application v." . self::VERSION");
    }

} ?>

Yeah, I can think of a million examples where I've done something like that. (Like my PreparedStatement / Statement example.) Hans