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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
