php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #46851 Strict standards: Declaration of ... should be compatible with that of ...
Submitted: 2008-12-12 16:08 UTC Modified: 2010-07-11 16:45 UTC
Votes:1
Avg. Score:2.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: oliver at teqneers dot de Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 5.2.8 OS: OpenSuSE 11.0
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: oliver at teqneers dot de
New email:
PHP Version: OS:

 

 [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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-12-17 11:12 UTC] bjori@php.net
Set error_reporting in your php.ini and you'll see the error.

 [2010-05-28 17:24 UTC] travis dot crowder at spechal dot com
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 5
 [2010-06-30 02:18 UTC] mauricio at yoreparo dot com
Still 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.
 [2010-06-30 03:13 UTC] mauricio at yoreparo dot com
Also tried on PHP 5.3.2, an issue too.

thanks
 [2010-06-30 09:48 UTC] colder@php.net
It is simply related to the fact that if the classes are in the right order, they 
get defined at compile time and hence that strict error happens at compile-time, 
which is before you actually set to display E_STRICT.
 [2010-07-11 14:48 UTC] 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?
 [2010-07-11 16:45 UTC] colder@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.
 [2010-07-14 21:46 UTC] demaio at vanylla dot it
I sthis a PHP bug then?
Is this bug going to be fixed?
 [2010-11-09 02:49 UTC] 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.
 [2011-08-03 21:32 UTC] 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.
 [2012-02-09 06:10 UTC] 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; }
}
 [2012-02-11 19:10 UTC] ldr at ldrutledge dot com
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.
 [2015-01-21 16:01 UTC] t dot kmieliauskas at gmail dot com
Hey, 2008 called, they said they wanted their errors back!

Still valid in 5.5.12...
 [2015-01-21 16:01 UTC] t dot kmieliauskas at gmail dot com
Hey, 2008 called, they said they wanted their errors back!

Still valid in 5.5.12...
 [2016-08-26 02:29 UTC] luoziluojun at 126 dot com
it's not resolve at 2016/8/26
 [2018-01-02 06:07 UTC] 164551317 at qq dot com
it's not resolve at 2018-1-2 in PHP7.0.12-NTS
 [2018-01-02 06:12 UTC] spam2 at rhsoft dot net
there is nothing to resolve

as explained set it in php.ini and forget about the idea to raise error-logging which happens at *compile time* within scripts or do it in your bootstrap before the includes are loaded
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Nov 23 23:01:26 2024 UTC