rfc:prototype_checks
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:prototype_checks [2011/09/19 11:19] – [Allowed] colder | rfc:prototype_checks [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Request for Comments: | + | ====== Request for Comments: |
* Version: 1.0 | * Version: 1.0 | ||
* Date: 2011-09-19 | * Date: 2011-09-19 | ||
* Author: Etienne Kneuss < | * Author: Etienne Kneuss < | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
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 existing 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 ==== | ||
+ | Scenario: | ||
+ | |||
+ | abstract class ParentAbs { | ||
+ | abstract public function foo($a); | ||
+ | } | ||
+ | abstract class SubAbs extends ParentAbs { | ||
+ | abstract public function foo($a); | ||
+ | } | ||
+ | | ||
+ | NOT allowed, always result in a fatal error even if the prototypes are compatible. | ||
+ | |||
+ | ==== Overriding interface method ==== | ||
+ | Scenario: | ||
+ | |||
+ | interface ParentIface { | ||
+ | function foo($a); | ||
+ | } | ||
+ | interface SubIface extends ParentIface { | ||
+ | function foo($a); | ||
+ | } | ||
+ | | ||
+ | NOT allowed, always result in a fatal error even if the prototypes are compatible. | ||
+ | |||
+ | | ||
===== Current rules ===== | ===== Current rules ===== | ||
- | This part specifies what is currently considered as a compatible signature: | ||
==== Allowed ==== | ==== Allowed ==== | ||
+ | This part specifies what is currently considered as valid signature modifications: | ||
+ | |||
=== Adding new optional arguments === | === Adding new optional arguments === | ||
function foo($a) | function foo($a) | ||
- | becomes | + | is compatible with, in a sub class: |
function foo($a, $b = 42) | function foo($a, $b = 42) | ||
Line 40: | Line 72: | ||
function foo($a) | function foo($a) | ||
- | becomes | + | is compatible with, in a sub class: |
function & | function & | ||
+ | ==== Mismatch ==== | ||
+ | This part specifies what is currently considered as invalid signature modifications: | ||
+ | |||
+ | === Strenghtening the type hint === | ||
+ | Given: | ||
+ | class A {} | ||
+ | class B extends A{} | ||
+ | |||
+ | function foo(A $a) | ||
+ | is imcompatible with, in a sub class: | ||
+ | function foo(B $a) | ||
+ | |||
+ | === Removing a return by ref === | ||
+ | |||
+ | function &foo() | ||
+ | is imcompatible with, in a sub class: | ||
+ | function foo() | ||
+ | |||
+ | |||
+ | === Adding a mandatory argument === | ||
+ | |||
+ | function foo() | ||
+ | is imcompatible with, in a sub class: | ||
+ | function foo($a) | ||
+ | |||
+ | ==== Mismatch but theoretically compatible ==== | ||
+ | |||
+ | This part specifies what is currently considered as invalid modifications, | ||
+ | |||
+ | === Removing the type hint === | ||
+ | |||
+ | function foo(Array $a) | ||
+ | is currently imcompatible with, in a sub class: | ||
+ | function foo($a) | ||
+ | |||
+ | === Weakening the type hint === | ||
+ | Given: | ||
+ | class A {} | ||
+ | class B extends A{} | ||
+ | |||
+ | function foo(B $a) | ||
+ | is currently imcompatible with, in a sub class: | ||
+ | function foo(A $a) | ||
+ | |||
+ | === Arg no longer by ref === | ||
+ | |||
+ | function foo(& | ||
+ | is currently imcompatible with, in a sub class: | ||
+ | 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, | ||
+ | |||
+ | - 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 { | ||
+ | | ||
+ | // ... | ||
+ | } | ||
+ | | ||
+ | class C implements A, B { .. } | ||
+ | This is currently not allowed, but there is no reason why it shouldn' |
rfc/prototype_checks.1316431187.txt.gz · Last modified: 2017/09/22 13:28 (external edit)