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
This part specifies what is currently considered as a compatible signature:
Allowed
Adding new optional arguments
function foo($a)
becomes in a sub class/interface
function foo($a, $b = 42)
Adding a return-by-ref
function foo($a)
becomes in a sub class/interface
function &foo($a)