Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81838
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
Message-ID: <54D27B45.5060200@gmail.com>
Date: Wed, 04 Feb 2015 20:04:21 +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>
In-Reply-To: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090709030507040802090504"
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: rowan.collins@gmail.com (Rowan Collins)

--------------090709030507040802090504
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Nikita Popov wrote on 04/02/2015 18:49:
> 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.


For those that missed it, or have forgotten, there was a discussion of 
covariance and contravariance in November, kicked off by Levi's concerns 
over return type hints: 
http://grokbase.com/t/php/php-internals/14bstfz0pg/rfc-discussion-return-type-variance-checking

In particular, this Wikipedia article explains the concepts very well 
(although once you get into generics it all gets a bit complicated, and 
irrelevant to us right now): 
http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) 
<http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29#Covariant_method_return_type>

Removing the typehint is a special case of contravariance, because it 
means "accept any type", and parameter contravariance in a nutshell is 
"a child implementation must accept at least what the parent accepts, 
but may also accept more".

The current situation (invariance) is quite intuitive - the signatures 
must match - and full contravariance can be explained fairly easily - 
"B:method must accept all values accepted by A::method". My worry is 
that people won't understand why this particular special case is 
allowed, and may think PHP is just letting them be sloppy and remove 
other people's type hints.

The other thing to consider is whether the same special case should be 
added (in reverse) to return type hints - a sub-class could *introduce* 
a return type hint, as long as the parent class did not already declare one.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------090709030507040802090504--