Edit report at https://bugs.php.net/bug.php?id=46851&edit=1
ID: 46851
Comment by: eyal dot t at zend dot com
Reported by: oliver at teqneers dot de
Summary: Strict standards: Declaration of ... should be
compatible with that of ...
Status: Not a bug
Type: Bug
Package: Scripting Engine problem
Operating System: OpenSuSE 11.0
PHP Version: 5.2.8
Block user comment: N
Private report: N
New Comment:
was wondering why the order of the class declarations affects whether a notice
is given, that is while
abstract class B extends A {
public static function foo($str){ echo $str; }
}
abstract class A {
public static function foo(){ echo 'bar'; }
}
causes the strict standard notice to show, the reversed order does not:
abstract class A {
public static function foo(){ echo 'bar'; }
}
abstract class B extends A {
public static function foo($str){ echo $str; }
}
Previous Comments:
------------------------------------------------------------------------
[2011-08-03 21:32:13] josh dot x dot guthrie at gmail dot com
This is not a bug in PHP, this is a flaw in your understanding of PHP and how
it
handles method overloading. If your child class inherits from the parent class
and you override one of the parent class's methods, you must still pass it the
same number of parameters. Ex:
abstract class B extends A {
public static function foo($str){ echo $str; }
}
abstract class A {
public static function foo(){ echo 'bar'; }
}
What you will notice is that class A has a method "foo" which takes no
parameters. We then extend A with class B which overrides the method "foo" and
gives it a parameter "$str". This method overload is causing the strict error.
If you want a fix, make the parameter optional and it should remove the strict
warning. This fix has been tested with the __autoload function for class
loading.
------------------------------------------------------------------------
[2010-11-09 02:49:37] gabriel dot delepine at gmail dot com
I have exactly the same problem.
Autoload() is called for the subclass before the class. A error E_STRICT is
throw.
I use PHP 5.3.2-1 on Ubuntu Serveur 10.04
It append for me when I use the design pattern sigleton and when I call the
function getInstance() of the subclass. This function have to return an
instance
of the subclass but the error E_STRICT is throw.
I check the change log of PHP 5.3.3-1 but I seen nothing about this.
------------------------------------------------------------------------
[2010-07-14 21:46:58] demaio at vanylla dot it
I sthis a PHP bug then?
Is this bug going to be fixed?
------------------------------------------------------------------------
[2010-07-11 16:45:07] [email protected]
What change?
The error is in both cases here, only that in one case, it is not displayed
because at the time it is emitted, error_reporting does not contain E_STRICT
(.e. php.ini).
It's not about ensuring class loading order. It is simply that if you define
classes in a "wrong" order, or if you use autoload, classes loading will get
postponed at runtime, hence errors will be triggered at runtime i.e. after the
error_reporting call.
------------------------------------------------------------------------
[2010-07-11 14:48:04] david at customcode dot co dot za
Surely this counts as a bug when you consider it in the context of applications
that make extensive use autoload. I realise I am a bit late to this party but
from what I can see the strict standard was changed in php 5.2.10 but I can't
seem to find any mention of this change in the changelog. This appears to be a
fairly major change potentially affecting alot of people's code. I would expect
at least some documentation of the rationale behind the change and at least
some guidelines. That being said, surely when it comes to ensuring that classes
are loaded/compiled in the correct order, classes that needed to be autoloaded
should be loaded first before the child class is compiled. Or am I missing
something?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=46851
--
Edit this bug report at https://bugs.php.net/bug.php?id=46851&edit=1
