Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81910
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
Message-ID: <54D35FEC.7080902@gmail.com>
Date: Thu, 05 Feb 2015 12:19:56 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com> <CADNQb0Wy8nsMJ3yO1D=bXq3YW-k8-6s7_97xzAv1rNAdG0cuAg@mail.gmail.com>
In-Reply-To: <CADNQb0Wy8nsMJ3yO1D=bXq3YW-k8-6s7_97xzAv1rNAdG0cuAg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: rowan.collins@gmail.com (Rowan Collins)

Hannes Magnusson wrote on 04/02/2015 23:58:
> On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov <nikita.ppv@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]