This is an old revision of the document!
Request for Comments: How to write RFCs
- Version: 1.0
- Date: 2011-09-19
- Author: Etienne Kneuss colder@php.net
- Status: Under Discussion
- First Published at: http://wiki.php.net/rfc/prototype_checks
Introduction
Past discussions on the mailing lists have shed some light on the various ways we handle prototype checks and what may be done to improve PHP in that area. This RFC summarizes the current state (5.3/5.4) of prototype checks and possible improvements to it
Prototype checks
Prototype checks occur in different contexts:
Implementing abstract method
The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a FATAL error.
Implementing interface method
The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a FATAL error.
Overriding concrete method
The prototype is checked with current normal rules (see Current rules). Any mismatch with current rules generates a STRICT error.
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
Allowed
This part specifies what is currently considered as valid signature modifications:
Adding new optional arguments
function foo($a)
is compatible with, in a sub class:
function foo($a, $b = 42)
Adding a return-by-ref
function foo($a)
is compatible with, in a sub class:
function &foo($a)
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, despite being theoretically sound:
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(&$a)
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()