Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c81zLAWvV9d5mgX1krjyvEpzZm_3MQvJ1gcbrGeKwRHaA@mail.gmail.com>
References: <CAFMT4Npco8sQ-+5hpUNa3pu5L2q7mnCVnsCjZee=NbNDrkwLUw@mail.gmail.com>
 <5474EF98.8070602@mabe.berlin> <CAFMT4NqThfke79_71cx1jACdb3dwgKRgvxZ6VqFtpNH5VycSkw@mail.gmail.com>
 <5474FF0C.4010405@mabe.berlin> <CAF+90c81zLAWvV9d5mgX1krjyvEpzZm_3MQvJ1gcbrGeKwRHaA@mail.gmail.com>
Date: Wed, 26 Nov 2014 11:21:12 +0100
Message-ID: <CAMyk_Aab41W2xiUxCY9dEoLemQJwUsFKKyOY=C1qRB02Jngo-w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Marc Bennewitz <dev@mabe.berlin>, Levi Morrison <levim@php.net>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b4722ae49be520508c064e3
Subject: Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
From: linepogl@gmail.com (Lazare Inepologlou)

--047d7b4722ae49be520508c064e3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014-11-25 23:42 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>:

> On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz <dev@mabe.berlin> wrote:
>
> >
> > 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 ofte=
n
> do
> >>> instantiation in base of unknown string values:
> >>>
> >>> class MyFactory {
> >>>      public static function factory($name) : AdapterInterface {
> >>>          $class =3D '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 a=
s
> > 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; }
> >
> > }
> >
>
> This is not correct. Parameter typehints in PHP are invariant, so you are
> not allowed to change them during inheritance. However LSP violations
> during inheritance of *non-abstract* methods currently uses a very low
> error level (E_STRICT), so you probably didn't notice. If you try the sam=
e
> thing with an interface method or an explicitly abstract method, you will
> receive a fatal error:
>
> interface I1 {
>     function foo(A $a);
> }
> class C1 implements I1 {
>     function foo(B $b) { ... }
> }
>
> This code snippet will result in a fatal error, because it violates type
> invariance.
>
>
Let's not compare these two:

* Parameter types are contravariant, otherwise they are not type sound.
Yet, contravariance in general is of little interest (I cannot think of any
practical example), so invariance is a good compromise.

* Return types are covariant. There are many useful examples already
mentioned in this mailing list.

http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_scienc=
e)#Covariant_method_return_type



Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel

--047d7b4722ae49be520508c064e3--