On Fri, 27 Feb 2004, Andi Gutmans wrote:
> d) Last problem is that using E_STRICT is not a good idea because we find > this problem at compile-time and the error_reporting might not be set yet.
The INI system is 'booted' before the script is compiled, so I doubt that this is a problem.
Yeah but people are used to setting the error_reporting from prepend's or at the beginning of the script. But you know what, I guess we can live with this because I see a few E_WARNINGS at the compile stage. So I guess we could go with E_STRICT for people who want to get the warning (and the script will still run).
The question is if we should ignore constructors from this check. I think we should but one person here thought we shouldn't.
> What I suggest is the following: > a) Don't check signature for constructors. > b) By default, don't check signature for inheritance *if* we're not > inheriting from an abstract class. If it is an abstract class we should > check the signature because it's a PHP 5 feature.
ack and ack
Is everyone OK with peforming this check for abstract classes and interfaces? Or do you think it should only be checked for E_STRICT (before our change it was checked! We only changed inheritance).
> c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out.
I'm against adding another INI setting. I don't see why we need to force this OO purist thing on all long time users at all. What is wrong by showing an e_notice/e_warning for it in non-compat mode, and e_strict in compat mode (or just e_strict in both cases)? Then PHP still tells you that you do something wrong, but it won't break any code.
That could work too. So in zend.ze2_compatibility_mode we'd do an E_STRICT and otherwise an E_WARNING? I think it's even OK if we just go with E_STRICT in all cases.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
