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 [email protected] to get a copy of this message

> -----Ursprüngliche Nachricht-----
> Von: Robert Stoll [mailto:[email protected]]
> 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:[email protected]]
> > 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 :)




Thread (24 messages)

« previous php.internals (#81837) next »