Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111886
User-Agent: Cyrus-JMAP/3.3.0-324-g0f99587-fm-20200916.004-g0f995879
Mime-Version: 1.0
Message-ID: <4608608e-906c-45d2-9f7e-e7f4213aa994@www.fastmail.com>
In-Reply-To: 
 <CAKuGYLSLm0aFVXdxcywzTAqbaohE--4zaaqFg9HYpDgQv6o=Pg@mail.gmail.com>
References: <09DE673B-71B7-4C8E-A795-900B51F8E476@stitcher.io>
 <CAKuGYLSLm0aFVXdxcywzTAqbaohE--4zaaqFg9HYpDgQv6o=Pg@mail.gmail.com>
Date: Thu, 17 Sep 2020 11:21:48 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] The case for transpiled generics
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Sep 17, 2020, at 10:21 AM, Matthew Brown wrote:
> Quick thing before I get into my own reaction:
>=20
> Transpiling is normally thought of as the process of converting one
> language into another. Tools like Babel transpile TypeScript to JavaSc=
ript.
>=20
> What's being proposed here (AFAICT) is type erasure =E2=80=93 the gene=
ric type
> information would be erased during the conversion to opcodes.
>=20
> Python (the language) has type erasure for all its types (including it=
s
> generic types), so no popular Python interpreters check that a functio=
n
> call's argument types match up with the function signature.
>=20
> PHP currently does not erase any types so the opcodes generated by PHP=
's
> interpreter include type checks for all the arguments passed to a type=
d
> function signature.
>=20
> Hack follows PHP's model, but erases generic types by default (though =
has
> more recently introduced the concept of reified generics) in much the =
same
> way you're proposing.

I concur; this is type elidiing, not transpiling.  Transpiling implies a=
 user-triggered pre-run step.  I know Sara has mused about it before but=
 it's not happened yet.

Basically what is being proposed (for those who need a concrete example)=
 is you'd write this:

class Collection<T> {

  public function add(T $item) { ... }

}
$c =3D new Collection<Product>().

And linters would recognize that, and it would parse, but at runtime it =
would compile to:

class Collection {

  public function add(mixed $item) { ... }

}
$c =3D new Collection().


And that's the opcodes that would be saved.  (I'm hand-waving a lot here=
.)

I would be on board with this, although I would ask if it's possible to =
provide some compile time checks; I'm thinking LSP validation, which is =
still relevant for inheritance with generics.  Beyond that, leave the ru=
ntime to not enforce it.  (I have no idea how viable that is, but Sara s=
eemed to think it would work so it probably would.)

Another possibility could be to desugar that original to:

class Collection {
  public $__T;

  public function add(mixed $item) {
    if (!$item instanceof $this->__T) {
      throw new TypeError();
    }
  }
}
$c =3D new Collection().
$c->__T =3D=3D 'Product';

Which is essentially what you can do in userspace today, but automated. =
 I don't know how viable that is, but it's another thing to consider.

--Larry Garfield