====== PHP RFC: Reclassify E_STRICT notices ======
  * Date: 2015-02-22
  * Author: Nikita Popov <nikic@php.net>
  * Status: Implemented (in PHP 7.0)

===== Introduction =====

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.

===== Proposal =====

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.

==== Indexing by a resource ====

<code php>
$file = fopen(__FILE__, 'r');
$array[$file] = true;

// Resource ID#3 used as offset, casting to integer (3)
</code>

Proposed resolution: Convert to ''E_NOTICE''.

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

==== Abstract static methods ====

<code php>
abstract class Foo {
	abstract static function bar();
}

// Static function Foo::bar() should not be abstract
</code>

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

==== "Redefining" a constructor ====

**Update**: This notice is already removed by [[https://wiki.php.net/rfc/remove_php4_constructors|the deprecation]] of PHP 4 constructors - this section is no longer relevant, just keeping it here for the overview.

<code php>
class Foo {
	function foo() {}
	function __construct() {}
}

// Redefining already defined constructor for class Foo
</code>

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.

==== Signature mismatch during inheritance ====

<code php>
class Foo {
	public function method() {}
}
class Bar extends Foo {
	public function method($arg) {}
}

// Declaration of Bar::method() should be compatible with Foo::method()
</code>

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.

==== Same (compatible) property in two used traits ====

<code php>
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.
</code>

Proposed resolution: Remove notice.

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

==== Accessing static property non-statically ====

<code php>
class Foo {
	public static $prop = 24;
}
$obj = new Foo;
$obj->prop = 42;

// Accessing static property Foo::$prop as non static
</code>

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.

==== Only variables should be assigned by reference ====

<code php>
$a =& substr("foo", 1);

// Only variables should be assigned by reference
</code>

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.

==== Only variables should be passed by reference ====

<code php>
function by_ref(&$ref) {}
by_ref(substr("foo", 1));

// Only variables should be passed by reference
</code>

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.

==== Calling non-static methods statically ====

<code php>
class Foo {
	public function method() {}
}
Foo::method();

// Non-static method Foo::method() should not be called statically
</code>

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.

===== Backward Incompatible Changes =====

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.

===== Vote =====

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

<doodle title="Reclassify E_STRICT notices as described in this RFC?" auth="nikic" voteType="single" closed="true">
   * Yes
   * No
</doodle>

===== Patch =====

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