AW: [PHP-DEV] Allow dropping typehints during inheritance

From: Date: Wed, 04 Feb 2015 19:23:58 +0000
Subject: AW: [PHP-DEV] Allow dropping typehints during inheritance
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-81836@lists.php.net to get a copy of this message
> -----Ursprüngliche Nachricht----- > Von: Nikita Popov [mailto:nikita.ppv@gmail.com] > Gesendet: Mittwoch, 4. Februar 2015 19:50 > An: PHP internals > Betreff: [PHP-DEV] Allow dropping typehints during inheritance > > Hi internals! > > Currently we do not allow [1] removing a typehint during inheritance. For example the following > code is not valid: > > interface A { > public function method(Typehint $param); > } > class B implements A { > public function method($param); > } > // Fatal error: Declaration of B::method() must be compatible with A::method(Typehint > $param) > > The above code does *not* constitute an LSP violation, because B::method() accepts more inputs > than A::method(). > However we still forbid it. > > This is an issue, because it makes it impossible to add typehints to parameters at a later > point in time. I've seen this issue > come up both in userland code, as well as in a recent DateTime change, see > > https://github.com/php/php-src/commit/8e19705a93d785cd1ff8ba3a69699b00169fea47 > . > > Instead of reverting the DateTime BC break, I'm wondering if it wouldn't be better to > fix the root cause by making the > inheritance check less strict and allow removing typehints? > > Thanks, > Nikita > > [1] This is a fatal error when interfaces or abstract methods are involved, otherwise this is > an E_STRICT error. I do not entirely agree here since what you are proposing is not to introduce contravariance for parameters (which I would support) but remove the check entirely. In this sense it is an LSP violation (you cannot substitute A with B and guarantee the correctness) and therefore should not be introduced into PHP. Cheers, Robert

« previous php.internals (#81836) next »