rfc:reclassify_e_strict

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:reclassify_e_strict [2015/02/22 22:04] – nikicrfc:reclassify_e_strict [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 2: Line 2:
   * Date: 2015-02-22   * Date: 2015-02-22
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
-  * Status: Draft+  * Status: Implemented (in PHP 7.0)
  
 ===== Introduction ===== ===== Introduction =====
Line 49: Line 49:
  
 ==== "Redefining" a constructor ==== ==== "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> <code php>
Line 61: Line 63:
 Proposed resolution: Remove notice. 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. This notice will already be removed by [[https://wiki.php.net/rfc/remove_php4_constructors|the deprecation]] of PHP 4 constructors, if it passes.+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 ==== ==== Signature mismatch during inheritance ====
Line 79: Line 81:
  
 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. 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.
- 
-Possible alternative: Convert to ''E_DEPRECATED'', if we intend to make this a fatal error in the future. 
  
 ==== Same (compatible) property in two used traits ==== ==== Same (compatible) property in two used traits ====
Line 118: Line 118:
 Proposed resolution: Convert to ''E_NOTICE'' Proposed resolution: Convert to ''E_NOTICE''
  
-Reason: +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 ==== ==== Only variables should be assigned by reference ====
Line 168: Line 168:
 ===== Vote ===== ===== Vote =====
  
-Requires a 2/3 majority, as it is a language change.+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 ===== ===== Patch =====
  
-TBD+https://github.com/php/php-src/pull/1177
rfc/reclassify_e_strict.1424642646.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools