Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116022
MIME-Version: 1.0
References: <CAMrTa2HYeKaE9E+A81HvSykpAD8ctd6aK9vtg_U15bYjyjzLKA@mail.gmail.com>
 <CADK1yXK=5=45mGFdTMZtw7=Zg2nsKKix335Goa9vYgZ5TjG93A@mail.gmail.com>
 <CAFPFaMLbHO4TC25NnEfh-FXFqwt9af3bBcjFJWDv=R+mP=3ADQ@mail.gmail.com> <756e4d26-2e57-4d31-83ea-28e756c3cc42@www.fastmail.com>
In-Reply-To: <756e4d26-2e57-4d31-83ea-28e756c3cc42@www.fastmail.com>
Date: Thu, 9 Sep 2021 05:44:09 +0200
Message-ID: <CAB-Bujb8yaGqRHJZ+4-3tuNfO0JvP=27Ls1t7a7hXi_gbF-6SA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Never For Argument Types
From: andreas@dqxtech.net (Andreas Hennings)

On Sat, 14 Aug 2021 at 15:05, Larry Garfield <larry@garfieldtech.com> wrote=
:
>
> On Sat, Aug 14, 2021, at 7:48 AM, G. P. B. wrote:
> > On Sat, 14 Aug 2021 at 10:55, Deleu <deleugyn@gmail.com> wrote:
> >
> > > Hi Jordan,
> > >
> > > Does it make sense to explain in the RFC the difference between never=
 and
> > > mixed in this context? The RFC vaguely mentions that never can never =
be
> > > used directly, but if it's limited to abstract class and interfaces, =
isn't
> > > that already impossible to use directly? Or does it mean that the typ=
e
> > > would "be allowed" on any function, but because of its intrinsic beha=
vior
> > > it would always fail if used in non-abstract methods?
> > >
> > > Another clarification I'd be interested is about dropping the type
> > > declaration entirely (e.g. https://3v4l.org/a4bfs), because of covari=
ance
> > > (or contravariance, I never know), sub classes can completely drop ty=
pe
> > > declaration entirely. Will never not allow this? Why? Why not? If it =
does
> > > allow this, does it really differ from not having any type declaratio=
n on
> > > the abstract function?
> > >
> > > My knowledge in this area is practically null so if I'm asking stupid
> > > questions that are easily explained by some blog post I'd he happy to=
 read
> > > it.
> > >
> >
> > never and mixed are on opposite sides of the type hierarchy.
> > mixed is the top type, meaning it's the supertype of any other types, a=
nd
> > any other type is a subtype of mixed (excluding void which is not reall=
y a
> > "type" if you look at it, from my understanding, in a type theory way).
> > never on the other side is the bottom type, meaning it's the subtype of=
 any
> > other type, and any other type is a supertype of never.
> > Finally a lack of type declaration is treated as mixed.
> >
> > Liskov's substitutions rules dictate that return types are co-variant i=
.e.
> > more specific, and argument types are contra-variant i.e. more general.
> > This is why any return type can be replaced by never and any argument t=
ype
> > can have it's type dropped/changed to mixed.
> > As such replacing never by mixed in an argument is totally possible as
> > mixed is a wider type than never.
> >
> > How I personally see never as an argument type is that you require a
> > mandatory argument but you leave the type constraint up to the
> > implementation.
> >
> > A recent example which bit us in php-src/the PHP documentation is the
> > interface of ArrayAccess, all of the $offset parameters have a mixed ty=
pe.
> > Until recently the ArrayObject/ArrayIterator had incorrect stubs [1] by
> > indicating that the argument was of type int|string, which practically =
is
> > the case as SPL's ArrayAccess handler will throw a TypeError on differe=
nt
> > types, however this is done manually within the call and not when the c=
all
> > is made.
> > Ideally the $offset parameter would be of type never such that SPL, and
> > userland, can specify what type of offsets they accept, be that the usu=
al
> > int|string, only int for list-like objects, only string for dictionary-=
like
> > objects, maybe even object|int|string to allow GMP objects for arbitrar=
y
> > precision.
> > Whereas every implementer of ArrayAccess is forced to accept mixed for =
the
> > $offset and need to manually enforce the type.
> >
> > This is the "power" of the never type as an argument type.
> >
> > Best regards,
> >
> > George P. Banyard
> >
> > [1]
> > https://github.com/php/php-src/pull/7215/files#diff-e330df347cac9e68d2d=
07a06535c534cd8c2438a1af703cd4245b8ce91ec65afL9-R10
>
> So... if I am following correctly, the idea is to allow `never` to be use=
d in an interface/abstract method only, as a way to indicate "you must spec=
ify a type here of some kind; I don't care what, even mixed, but you have t=
o put something".  Am I following?
>
> I'm not sure on the type theory of it, but it does feel like a hack at fi=
rst blush.

You don't have to specify a type.
When overriding the method in a child interface or abstract class, it
must have a parameter in the same place (and ideally with same name,
to support named argument calls).
The parameter in the overridden method may or may not have a type hint.
The parameter type hint can be "never", as in the parent, but then you
cannot call the method.

See also this older discussion, https://externals.io/message/100275#100300

Example:

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);
}

// In an ideal world, UniversalFruitEater would extend every other
FruitEater type, but that's not really possible.
interface UniversalFruitEater extends AbstractFoodEater /* ,
BananaEater, AppleEater */ {
  function eat(Fruit $fruit);
}

----

Btw, I wonder what this means for optional parameters.
Currently, "null" is not allowed as a parameter type hint, but it
would be a natural bottom type for "?*".
How narrow-minded of PHP!

E.g.

interface AbstractOptionalFruitEater {
  function eat(null $fruit);  // Not allowed, but would make sense here.
}

interface OptionalBananaEater extends AbstractFoodEater {
  function eat(?Banana $banana);
}

interface OptionalAppleEater extends AbstractFoodEater {
  function eat(?Apple $apple);
}

----------

I am not sure yet how useful this really is in practice, if we cannot
"close the circle" and have UniversalFruitEater extend all the other
FruitEater interfaces, and if we don't have generics.

The first idea would be a mapper that chooses a suitable eater like so:

abstract class MapperEaterBase implements UniversalFruitEater {
  public function eat(Fruit $fruit) {
    // IDE will get confused here, because it cannot verify that the
eater from findSuitableEater() is actually suitable.
    return $this->findSuitableEater($fruit)->eat($fruit);
  }
  abstract protected function findSuitableEater(Fruit $fruit):
AbstractFruitEater;
}

This would be a kind of userland "method overloading".
The "map of eaters" could be built with reflection, or with repeated
try/catch until one of them works.

However, I am still undecided whether this is the best way to achieve this.

I am currently building a system similar to this, but here every
implementation has a method that reports which types are supported.
My equivalent to the eat() method simply accepts anything, and then
uses instanceof internally to reject parameters with the wrong type.

The "never" type for parameters could provide some new possibilities here.


-- Andreas

>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>