Edit report at https://bugs.php.net/bug.php?id=46851&edit=1

 ID:                 46851
 Comment by:         ldr at ldrutledge 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:

I understand the discussion above. The warning is because some possible method 
calls may fail due to incomplete knowledge at compile-time.

However this causes the warning:

class A { public function foo(StdClass $a) {;}}
class B extends A { public function foo($a) {;}}

as does this:

class A { public function foo($a) {;}}
class B extends A { public function foo(StdClass $a) {;}}

In the case of 

function bar(A $a, A $b){$a->foo($b);}

The second form can fail at run-time, but the first can not and should not 
trigger the error.


Previous Comments:
------------------------------------------------------------------------
[2012-02-09 06:10:45] eyal dot t at zend dot com

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; }
}

------------------------------------------------------------------------
[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] col...@php.net

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.

------------------------------------------------------------------------


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

Reply via email to