On Feb 26, 2004, at 11:49 PM, Zeev Suraski wrote:
At 07:19 26/02/2004, Hans Lellelid wrote: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 (!)
If you take into account that [a] in PHP, you cannot have more than one signature for a method in a given class, and you take into account the fact that [b] your overriding method must be able to satisfy the same interface as the method its overriding (because it may be called from a context that was written to work with its parent method), then it all makes a lot of sense. You solution may be to declare PreparedStatement::executeQuery() with $sql=null as an argument that can be omitted, or even forces it to be omitted (if it's not null, display an error). It sounds to me as if you haven't taken [b] into account, and I guess there are many people that fall in that pitfall. But that's exactly what this error message comes to solve - if you don't take it into account, you are, in one way or another, developing error-prone code.
This is an enormously huge bc break. Error-prone or not, I would wager that 95%+ of all php4 OO code exploits the ability to redefine the signature on inherited methods. It also seems really against the spirit of PHP to enforce this sort of thing.
George
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
