|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2008-12-12 16:08 UTC] oliver at teqneers dot de
Description:
------------
If I turn on E_STRICT, I get a strict notice depending on class position. The notice is as following:
Strict standards: Declaration of ... should be compatible with that of ...
Maybe this notice is correct, but if I switch the classes in my code without changing their content, this notice is gone?!?
This is a problem when using autoload, because it might happen, that a subclass is loaded before the parent class has been parsed.
Reproduce code:
---------------
<?php
// this code does trigger a strict message
error_reporting( E_ALL | E_STRICT );
class cc extends c {
function test() { return null; }
}
class c {
function test( $a ) { return 1; }
}
$cc = new cc();
?>
<?php
// this code does NOT trigger a strict message
error_reporting( E_ALL | E_STRICT );
class c {
function test( $a ) { return 1; }
}
class cc extends c {
function test() { return null; }
}
$cc = new cc();
?>
Expected result:
----------------
None of the code blocks should trigger an error (my personal preference) or both code blocks must trigger a notice.
Actual result:
--------------
First block triggers:
Strict standards: Declaration of cc::test() should be compatible with that of c::test() in strict_test.php on line 4
Second does nothing at all.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Oct 29 00:00:01 2025 UTC |
Still an issue in 5.2.10 <?php error_reporting(E_ALL | E_STRICT); abstract class B extends A { public static function foo($str){ echo $str; } } class C extends A { public static function foo(){ echo 'baz'; } } abstract class A { public static function foo(){ echo 'bar'; } } C::foo(); Error: Strict Standards: Declaration of B::foo() should be compatible with that of A::foo() in /var/www/oop_test.php on line 5Still an issue on 5.2.13 when autoloading classes. Oliver code still triggers the STRICT error: <?php // this code does trigger a strict message error_reporting( E_ALL | E_STRICT ); class cc extends c { function test() { return null; } } class c { function test( $a ) { return 1; } } $cc = new cc(); ?> If I autoload the 'c' class the I get the STRICT error.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.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; } }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.