Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100277
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH0Uv3EW=KQy-DmfZrptd4LTYsudRNj+a+Ut_dcG=VG3+T9N_Q@mail.gmail.com>
References: <CAH0Uv3EW=KQy-DmfZrptd4LTYsudRNj+a+Ut_dcG=VG3+T9N_Q@mail.gmail.com>
Date: Tue, 22 Aug 2017 10:39:59 +0200
Message-ID: <CAF+90c_M3Pbpo0L066EeHYjgT6E1uWMuMmZiCYSbpbcaWY_EoQ@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c03564670e44d0557538aff"
Subject: Re: [PHP-DEV] Contravariance and the "empty type"
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c03564670e44d0557538aff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 22, 2017 at 4:27 AM, Andreas Hennings <andreas@dqxtech.net>
wrote:

> Hello list,
> for a while I had this thought about contravariance and an "empty type".
> I don't expect too much of it, for now I just want to share the idea.
> Maybe this concept even exists somewhere in a different language, and
> I am not aware of it.
>
> I think it has some overlap with generics, https://wiki.php.net/rfc/
> generics.
>
> ------------
>
> I think I am not the first one to suggest allowing contravariance for
> method parameters.
> E.g. here, "PHP RFC: Parameter Type Widening"
> https://wiki.php.net/rfc/parameter-no-type-variance
>
> From this RFC:
> > Unfortunately =E2=80=9Ctrue=E2=80=9D contravariance for class types isn=
't part of this
> RFC, as implementing that is far more difficult, and would require
> additional rules about autoloading and/or class compilation, which might
> only be acceptable at a major release.
>
> For anyone not familiar with the term:
>
> interface I {
>   function foo(J $arg);
> }
>
> interface J extends I {
>   function foo(I $arg);
> }
>
> So: While return types in a child method should be either the same or
> more narrow, the parameter types should be either the same or more
> permissive.
> Without this it would break Liskov substitution.
>
> ---------------
>
> Now for my actual proposal: The "empty type".
> We can think of a type (class/interface or primitive) as a set or a
> constraint on the kind of values that it allows.
> There is a special type, "mixed", which allows all values. We could
> also think of it as the union of all types.
>
> A natural extension of this concept, on the other end, would be a type
> "nothing" or "empty", which would allow no values at all.
> We could think of this as the intersection of all types.
> In fact it is already sufficient to intersect just two distinct
> primitive types to get this empty type:
> "All values that are at the same time string and integer" clearly is
> an empty type.
>
> How would this ever be useful?
> If we write a base class or interface for a category of interfaces
> that have a similar signature.
>
> interface Fruit {..}
> interface Apple extends Fruit {..}
> interface Banana extends Fruit {..}
>
> interface AbstractFruitEater {
>   function eat(EMPTY_TYPE $fruit);
> }
>
> interface BananaEater extends AbstractFoodEater {
>   function eat(Banana $banana);
> }
>
> interface AppleEater extends AbstractFoodEater {
>   function eat(Apple $apple);
> }
>
> One could imagine a component that has a list of AbstractFruitEater
> objects, and chooses one that is suitable for the given fruit, using
> instanceof.
> I think the correct term is "chain of responsibility".
>
> function eatApple(array $fruitEaters, Apple $apple) {
>   foreach ($fruitEaters as $eater) {
>     if ($eater instanceof AppleEater) {
>       $eater->eat($apple);
>       break;
>     }
>   }
> }
>
> --------------------
>
> We can go one step further.
>
> The natural parameter type to use for param $fruit in
> AbstractFruitEater::foo() would not be the global EMPTY_TYPE, but
> something more specific:
> The projected intersection of all real and hypothetical children of
> interface Fruit.
> Obviously this does not and cannot exist as a class or interface.
>
> Practically, for the values it allows, this is the same as the global
> EMPTY_TYPE.
> But unlike the EMPTY_TYPE, this would poses a restriction on the
> parameter type in child interfaces.
>
> What would be the syntax / notation for such a projected hypothetical
> subtype?
> I don't know. Let's say INTERSECT_CHILDREN<Fruit>
>
> So, would the following work?
>
> interface Food {..}
> interface Fruit extends Food {..}
> interface Banana extends Fruit {..}
>
> interface AbstractFoodEater {
>   function eat(INTERSECT_CHILDREN<Food> $food);
> }
>
> interface AbstractFruitEater extends AbstractFoodEater {
>   function eat(INTERSECT_CHILDREN<Fruit> $fruit);
> }
>
> interface BananaEater extends AbstractFruitEater {
>   function eat(Banana $banana);
> }
>
> I'm not sure.
> Liskov would not care. Both AbstractFoodEater and AbstractFruitEater
> are useless on their own.
> Maybe there are other logical conflicts which I don't see.
>
>
> ----------
>
> Obviously with generics this base interface would no longer be relevant.
> https://wiki.php.net/rfc/generics
>
> interface FruitEater<FruitType> {
>   function eat(FruitType $fruit);
> }
>
> // This is not really necessary.
> interface BananaEater extends FruitEater<Banana> {
>   function eat(Banana $banana);
> }
>
> So, would the "empty type" become obsolete? Maybe.
> I did not arrive at a final conclusion yet. It still seems too
> interesting to let it go.
>
> -- Andreas
>

What's the purpose of this construction? I get the general idea (work
around LSP variance restrictions without generics), but I don't see how the
practical use would look like. After all, using the empty type as an
argument implies that the method may not ever be called, so wouldn't an
interface using it be essentially useless?

Nikita

--94eb2c03564670e44d0557538aff--