Andi Gutmans wrote:
The question is if we should ignore constructors from this check. I think we should but one person here thought we shouldn't.
I think constructors should be ignored.
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).
I tend to think that for consistency interfaces should be allowed to override method signatures (i.e. when extending an interface you can change it), but agree that this is technically wrong/bad behavior.
Just a though -- would it make sense to have another keywords / method that does a strict isA check? -- i.e. if ($obj strictinstanceof Statement). This would allow developers to make those signature-conforming assumptions that they cannot make in PHP now.
> 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.
I'd prefer E_STRICT always, if anything, since I want to be able to design PHP5 code that takes advantage of loose inheritance checking w/o requiring users to enable compatibilty mode.
Hans
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
