Hannes Magnusson wrote on 04/02/2015 23:58:
On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov <nikita....@gmail.com> wrote:
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.
So what it supports "more inputs"?
It does constitute an LSP violation. "more inputs" is not what the
guarantee is at all, if that is what you want you'd typehint on a
interface.

Have a look at the Wikipedia article on covariance and contravariance; the idea is that if you know you have a container which can contain Cats, a custom implementation that also happens to accept Dogs is fine, but an implementation that only accepts Kittens is not, because the object is contractually required to accept any Cat that you give it.

Return types are the reverse, because the object is contractually required to return you nothing but Cats, so returning a Dog would be a violation; but constraining itself to only return Kittens doesn't affect the contract you have with it.

The special case proposed here is that the lack of type hint means "any type", as though you were type hinting the base of all possible types. Thus removing a typehint on a parameter does not allow the object to violate the parent's contract, and nor does adding a return typehint.

However, the fact that this is tricky to understand is probably a big problem for it. The Wikipedia article notes that few languages implement parameter contravariance, mostly because they'd have to mix it with type-based function overloading, making real-life examples hard to find.

Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to