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

At 14:13 27/02/2004 +0100, Derick Rethans wrote:

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