PHP RFC: Reclassify E_STRICT notices

• Date: 2015-02-22
• Author: Nikita Popov nikic@php.net
• Status: Implemented (in PHP 7.0)

This RFC proposes to reclassify the few existing E_STRICT notices and remove this error category.

This is accomplished by doing one of the following:

• Remove the strict standards notice if it appears inconsistent or informational.
• Promote to E_DEPRECATED if there is intent to remove this functionality in the future.
• Promote to E_NOTICE or E_WARNING otherwise.

The motivation behind this change is to simplify our error model and resolve the currently unclear role of strict standards notices.

The following section lists all strict standards notices currently in use (with code sample and error message) as well as the proposed resolution and the reasoning behind it.

The E_STRICT constant will be retained for better compatibility, it will simply no longer have meaning in PHP 7.

$file = fopen(__FILE__, 'r');
$array[$file] = true;
 
// Resource ID#3 used as offset, casting to integer (3)

Proposed resolution: Convert to E_NOTICE.

Reason: E_NOTICE is also used for array to string and object to int/float conversions.

abstract class Foo {
	abstract static function bar();
}
 
// Static function Foo::bar() should not be abstract

Proposed resolution: Remove notice.

Reason: We currently allow the use of abstract static functions in interfaces, as such it is inconsistent to not allow them as abstract methods. By using late static binding a method in the abstract class can reasonably depend on the existence of a static method in a superclass. (As far as any usage of LSB can be considered reasonable).

Update: This notice is already removed by the deprecation of PHP 4 constructors - this section is no longer relevant, just keeping it here for the overview.

class Foo {
	function foo() {}
	function __construct() {}
}
 
// Redefining already defined constructor for class Foo

Proposed resolution: Remove notice.

Reason: If a PHP 5 constructor exists, the PHP 4 constructor will be a normal method, as such the notice is somewhat bogus. It is also order dependent, i.e. it will not be thrown if the order of foo and __construct is swapped.

class Foo {
	public function method() {}
}
class Bar extends Foo {
	public function method($arg) {}
}
 
// Declaration of Bar::method() should be compatible with Foo::method()

Proposed resolution: Convert to E_WARNING.

Reason: If the same signature mismatch occurs when implementing an interface or an abstract function a fatal error is thrown instead of a strict standards notice. A signature mismatch is a significant issue, which will likely prevent the use of the child object in place of the parent object.

trait A {
	public $prop;
}
trait B {
	public $prop;
}
class C {
	use A, B;
}
 
// A and B define the same property ($prop) in the composition of C.
// This might be incompatible, to improve maintainability consider
// using accessor methods in traits instead.

Proposed resolution: Remove notice.

Reason: This appears to be a purely informational notice about coding style.

class Foo {
	public static $prop = 24;
}
$obj = new Foo;
$obj->prop = 42;
 
// Accessing static property Foo::$prop as non static

Proposed resolution: Convert to E_NOTICE

Reason: E_NOTICE is used for a number of other property related noticed, like indirect modification or undefined properties. Accessing a static property non-statically makes it look like the property is only changed on the object, which is not true.

$a =& substr("foo", 1);
 
// Only variables should be assigned by reference

Proposed resolution: Convert to E_NOTICE

Reason: E_NOTICE is used when you try to return the result of a by-value function call by-reference, which is a conceptually similar situation.

function by_ref(&$ref) {}
by_ref(substr("foo", 1));
 
// Only variables should be passed by reference

Proposed resolution: Convert to E_NOTICE

Reason: E_NOTICE is used when you try to return the result of a by-value function call by-reference, which is a conceptually similar situation.

class Foo {
	public function method() {}
}
Foo::method();
 
// Non-static method Foo::method() should not be called statically

Proposed resolution: Convert to E_DEPRECATED

Reason: This is already deprecated if the call occurs from an instance method. Not annotating methods as static is an obsolete PHP4-ism.

Some of the strict standards notices are converted to an error category that is considered more severe. As such error handlers might treat it more severely, resulting in BC breakage.

The E_STRICT constant will be retained, as such existing error_reporting(E_ALL|E_STRICT) calls will continue to work fine.

Requires a 2/3 majority, as it is a language change. Voting started on 2015-03-15 and ended on 2015-03-25.

Reclassify E_STRICT notices as described in this RFC?
Real name	Yes	No
adobkin (adobkin)
aharvey (aharvey)
ajf (ajf)
brandon (brandon)
bwoebi (bwoebi)
chx (chx)
Damien Tournoud (damz)
davey (davey)
eliw (eliw)
frozenfire (frozenfire)
jedibc (jedibc)
jwage (jwage)
kguest (kguest)
kinncj (kinncj)
laruence (laruence)
lcobucci (lcobucci)
levim (levim)
mbeccati (mbeccati)
nikic (nikic)
pajoye (pajoye)
patrickallaert (patrickallaert)
pauloelr (pauloelr)
philstu (philstu)
ramsey (ramsey)
rdohms (rdohms)
rmf (rmf)
santiagolizardo (santiagolizardo)
stas (stas)
stelianm (stelianm)
theseer (theseer)
timo (timo)
yunosh (yunosh)
Final result:	28	4
This poll has been closed.

https://github.com/php/php-src/pull/1177