Hi Matthew and Larry
> On 17 Sep 2020, at 18:21, Larry Garfield <la...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
