Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79182
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error)
Message-ID: <5474FF0C.4010405@mabe.berlin>
Date: Tue, 25 Nov 2014 23:13:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Levi Morrison <levim@php.net>
CC: internals <internals@lists.php.net>
References: <CAFMT4Npco8sQ-+5hpUNa3pu5L2q7mnCVnsCjZee=NbNDrkwLUw@mail.gmail.com>	<5474EF98.8070602@mabe.berlin> <CAFMT4NqThfke79_71cx1jACdb3dwgKRgvxZ6VqFtpNH5VycSkw@mail.gmail.com>
In-Reply-To: <CAFMT4NqThfke79_71cx1jACdb3dwgKRgvxZ6VqFtpNH5VycSkw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
From: dev@mabe.berlin (Marc Bennewitz)


Am 25.11.2014 um 22:43 schrieb Levi Morrison:
> On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz <dev@mabe.berlin> wrote:
>> I think it's required to do the type check on runtime (Option 2) because
>> one of the use cases for return type-hint are factories and such often do
>> instantiation in base of unknown string values:
>>
>> class MyFactory {
>>      public static function factory($name) : AdapterInterface {
>>          $class = 'MyNamespace\Adapter\' . $name;
>>          return $class();
>>      }
>> }
> It seems that I did not explain this clearly enough; I apologize. The
> variance has to do with the declared type in the function signature
> when inheritance is involved, not the type of the value returned by
> the function.
>
> For instance, under any of the three options this code will work just fine:
>
> class Foo {}
> class Goo  extends Foo {}
>
> class FooFactory {
>      function create(): Foo { return new Goo(); }
> }
>
> As long as the return value from FooFactory::create returns Foo or a
> subtype of Foo (such as Goo), then it will work.
>
> The variance that is under discussion in this thread is about the
> declared return type in the signature:
>
> class GooFactory extends FooFactory {
>      function create(): Goo {}
> }
>
> In this case, GooFactory::create() declares a return type of Goo,
> which is a subtype of Foo [the return type of the inherited method
> FooFactory::create()]. This is a covariant return type.
>
> If we choose option 3, the only possible return type for
> GooFactory::create is Foo.
>
> Hopefully this clarifies the issue.
Yes it does - thank you for explanation - my mistake :/

Option 3 is a no go not from OOP perspective and from consistency pov as 
we already allow this in type-hint:

class FooFactory {
     function create(Foo $foo): Foo { return $foo; }
}

class GooFactory extends FooFactory {
     function create(Goo $goo): Goo { return $goo; }
}