AW: [PHP-DEV] Allow dropping typehints during inheritance
| From: | Robert Stoll | 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