rfc:prototype_checks

This is an old revision of the document!


Request for Comments: How to write RFCs

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()
rfc/prototype_checks.1316432434.txt.gz · Last modified: 2017/09/22 13:28 (external edit)