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
rfc:prototype_checks [2011/09/19 11:38] – colderrfc:prototype_checks [2017/09/22 13:28] (current) – external edit 127.0.0.1
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.1316432317.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools