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
Last revisionBoth sides next revision
rfc:reclassify_e_strict [2015/02/22 22:32] – nikicrfc:reclassify_e_strict [2015/04/01 09:59] – nikic
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: Under Discussion+  * 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 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.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools