Re: The case for transpiled generics

Hi Matthew and Larry > On 17 Sep 2020, at 18:21, Larry Garfield <larry@garfieldtech.com> wrote: > > On Thu, Sep 17, 2020, at 10:21 AM, Matthew Brown wrote: >> Quick thing before I get into my own reaction: >> >> Transpiling is normally thought of as the process of converting one >> language into another. Tools like Babel transpile TypeScript to JavaScript. I looked up the definition [1] before writing my mail and it said > A […] transpiler is a type of translator that takes the source code of a program written in a > programming language as its input and produces an equivalent source code in the same or a different > programming language But I don't want to get stuck on phrasing, if elidiing is the right term as Larry suggests, let's go with it! >> >> What's being proposed here (AFAICT) is type erasure – the generic type >> information would be erased during the conversion to opcodes. >> >> Python (the language) has type erasure for all its types (including its >> generic types), so no popular Python interpreters check that a function >> call's argument types match up with the function signature. I didn't know about Python's approach before, and I think it's validating the idea, it's at least something worth looking into. >> >> 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 typed >> function signature. >> >> 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 = 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 = 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 runtime to not enforce it. (I have no idea how viable that is, > but Sara seemed to think it would work so it probably I agree that's an approach worth looking into. I didn't want to discuss specifics yet, and first get a feel of what people think of the general idea, but it's good that you're mentioning this, and I'm glad others are open to the idea. > > 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 = new Collection(). > $c->__T == '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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Kind regards Brent [1] https://en.wikipedia.org/wiki/Source-to-source_compiler