Thanks for the response.
Zeev Suraski wrote:
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.
Yes, this does make sense when interfaces are involved (as they are in my PreparedStatement example). It's more that it's frustrating because the way around this is kludgy, and I'm not sure what's worse: a "loose" OO inheritance model or kludgy code as the solution to workaround a strict model.
I agree with others that E_STRICT error for method signature change would be fine. I think to raise a fatal error would break way too much PHP4 (and PHP5) code.
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).
Yeah, this feels like the kind of hack that I would like to avoid. If you always throw an Exception when $sql is set in PreparedStatement, then in *practice* this is really no different from breaking the isA contract since the method cannot be used with same signature as parent method. In my case I just chose not to inherit PreparedStatement from Statement; that way I can change the method signatures without problems arising from the inherited interfaces. Not ideal, but it works.
Constructors will probably have to be dealt with differently.
Good -- whew :)
Thanks- Hans
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
