rfc:prototype_checks

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:prototype_checks [2011/09/19 11:38] – colderrfc:prototype_checks [2014/04/08 22:52] – Inactive levim
Line 1: Line 1:
-====== Request for Comments: How to write RFCs ======+====== Request for Comments: Prototype checks ======
   * Version: 1.0   * Version: 1.0
   * Date: 2011-09-19   * Date: 2011-09-19
   * Author: Etienne Kneuss <colder@php.net>   * Author: Etienne Kneuss <colder@php.net>
-  * Status: Under Discussion+  * Status: Inactive
   * First Published at: http://wiki.php.net/rfc/prototype_checks   * First Published at: http://wiki.php.net/rfc/prototype_checks
  
Line 16: Line 16:
  
 ==== Implementing abstract method ==== ==== Implementing abstract method ====
 +=== Normal methods ===
 The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a FATAL error. The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a FATAL error.
 +=== Constructors ===
 +  * In 5.3: No checks are performed
 +  * In 5.4: The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a FATAL error.
  
 ==== Implementing interface method ==== ==== Implementing interface method ====
 +=== All Methods ===
 The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a FATAL error. The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a FATAL error.
 +
  
 ==== Overriding concrete method ==== ==== Overriding concrete method ====
 +=== Normal methods ===
 The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a STRICT error. The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a STRICT error.
 +=== Constructors === 
 +No checks are performed.
  
 ==== Overriding abstract method ==== ==== Overriding abstract method ====
Line 88: Line 93:
   function foo()   function foo()
  
 +
 +=== Adding a mandatory argument ===
 +
 +  function foo()
 +is imcompatible with, in a sub class:
 +  function foo($a)
  
 ==== Mismatch but theoretically compatible ==== ==== Mismatch but theoretically compatible ====
Line 96: Line 107:
  
   function foo(Array $a)   function foo(Array $a)
-is imcompatible with, in a sub class:+is currently imcompatible with, in a sub class:
   function foo($a)   function foo($a)
  
Line 105: Line 116:
  
   function foo(B $a)   function foo(B $a)
-is imcompatible with, in a sub class:+is currently imcompatible with, in a sub class:
   function foo(A $a)   function foo(A $a)
  
Line 111: Line 122:
  
   function foo(&$a)   function foo(&$a)
-is imcompatible with, in a sub class:+is currently imcompatible with, in a sub class:
   function foo($a)   function foo($a)
  
 +
 +=== Requiring less arguments ===
 +
 +  function foo($a)
 +is currently imcompatible with, in a sub class:
 +  function foo()
 +
 +
 +===== Topics worth discussing =====
 +
 +==== Allow more theoretically valid modifications ====
 +
 +We have three wrong errors for modifications that should be accepted. Some of those might require more sophisticated checks than others, so not all might be worth including.
 +
 +==== Clarify the constructor problem ====
 +Constructors can be seen as pseudo-static methods, for this reason, the same checks for normal methods do not always apply for constructors.
 +
 +It is however unclear whether we really want, for constructors, to be more strict (and how strict) if they are defined via an abstract class. So:
 +
 +  - Do we really want that check to be performed on 5.4 for constructors coming from abstract methods
 +  - Do we really want the mismatch to result in a FATAL error (potential BC break coming from 5.3 where no checks were done)
 +
 +
 +==== Similar prototypes from different interfaces ====
 +It would be better to allow multiple interfaces to define the same intersection of prototype. It is currently not allowed in any case.
 +
 +For example:
 +
 +  interface A {
 +    function apply($a, $b);
 +    // ...
 +  }
 +  
 +  interface B {
 +     function apply($a, $b);
 +     // ...
 +  }
 +  
 +  class C implements A, B { .. }
 +
 +This is currently not allowed, but there is no reason why it shouldn't be.
rfc/prototype_checks.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools