Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81839
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <54D27B45.5060200@gmail.com>
References: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com>
 <54D27B45.5060200@gmail.com>
Date: Wed, 4 Feb 2015 21:26:22 +0100
Message-ID: <CAMUwpuTs5+dvfbsXbiQi70TgeXWOBd+B9=0-XF2tyUTZgCL0=w@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044288c89d0d4d050e490220
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: jpauli@php.net (Julien Pauli)

--f46d044288c89d0d4d050e490220
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 4, 2015 at 9:04 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> 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.
>


Whatever we choose, we must find a solution that is unique and spread into
all the core language and core exts.
And we have to think about BC : if we choose something more strict, we will
generate more BC breaks for the switch to PHP7, which is not really a good
thing.

However, I'm all good for us to find a clear solution on type parameters,
return types, extended type hints ... whatever other RFC will be accepted
about this kind of subject.
PHP7 should also be the moment we turn PHP into a more consistent, mature
and professional language.

And on the way to make the right choice, why not start by having a look at
what other languages provide ?

Julien Pauli

--f46d044288c89d0d4d050e490220--