Re: Declaration of Bar::__construct() must be compatible with that of Foo::__construct()
| From: | Andi Gutmans | Date: | Thu, 26 Feb 2004 07:12:25 +0000 |
| Subject: | Re: Declaration of Bar::__construct() must be compatible with that of Foo::__construct() | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-8153@lists.php.net to get a copy of this message | ||
At 08:03 26/02/2004 +0100, Timm Friebe wrote:
On Thu, 2004-02-26 at 07:49, Andi Gutmans wrote: At 23:36 25/02/2004 +0100, Timm Friebe wrote: [...] Guys, You are breaking the isA relationship. We fixed this so that from now on, people will not make such mistakes anymore (I think it's the right way to go, so that we don't leave broken functionality around). We do so ourselves: class Reflection_Function implements Reflector { public __construct(string name) public mixed invoke(mixed* args) } class Reflection_Method extends Reflection_Function { public __construct(mixed class, string name) public mixed invoke(stdclass object, mixed* args) } But, of course, the Engine checks are not imposed on internal classes.It does if the internal extension supplies ARG_INFO.
I'm just saying this is quite a BC break, whether it follows strict OOP rules or not.Yes, I understand that and I understand why you think it's a problem. The problem with E_STRICT is that people might think they can turn it on with error_reporting() but for this behavior to change (as it's compile time) it needs to be done via php.ini or htaccess. So I guess if you all prefer this as optional, we'd have to either add yet another INI directive or put it in E_STRICT (which as I mentioned will confuse people who are used to being able to change E_* from their scripts). Andi Andi