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

From: Date: Wed, 04 Feb 2015 19:36:38 +0000
Subject: AW: [PHP-DEV] Allow dropping typehints during inheritance
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-81837@lists.php.net to get a copy of this message
> -----Ursprüngliche Nachricht----- > Von: Robert Stoll [mailto:php@tutteli.ch] > Gesendet: Mittwoch, 4. Februar 2015 20:24 > An: 'Nikita Popov'; 'PHP internals' > Betreff: AW: [PHP-DEV] Allow dropping typehints during inheritance > > > > -----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/8e19705a93d785cd1ff8ba3a69699b00 > > 169fea47 > > . > > > > 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 > > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php I have to correct myself, without type hint is equal to say any type and in this sense it is contravariance, all good to go :)

« previous php.internals (#81837) next »