Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119455
Message-ID: <7d0714d0-5ee5-931c-4a76-07f69edc4f1c@gmail.com>
Date: Thu, 2 Feb 2023 22:20:18 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
To: internals@lists.php.net
References: <CABAhh3HfPOdsC6RJo2O6TCH1L09Zv4chfQg=UbuV1rNROSZJ4g@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CABAhh3HfPOdsC6RJo2O6TCH1L09Zv4chfQg=UbuV1rNROSZJ4g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Official Preprocessor
From: rowan.collins@gmail.com (Rowan Tommins)

On 02/02/2023 14:19, someniatko wrote:
> I suggest to introduce an official type-checker / static analyser /
> preprocessor / transpiler for PHP, somewhat similar to TypeScript in
> the JavaScript world, which will allow to introduce the features
> otherwise impossible for the PHP world, at the cost of including an
> additional transpilation step.


This is something I have thought about a lot over the years, and in some 
ways, it is very appealing; but it does have some problems.

One of the biggest is the concept of "type erasure": in a pre-processed 
or transpiled language, features like Reflection are crippled by not 
knowing the full information present in the source code. More 
importantly, dynamic language features - of which PHP has many - also 
have no access to the type information. That means that a List<Dog> can 
sometimes end up with a Cat in it at run-time, because a dynamic call 
doesn't know that's a problem.

I think it's interesting to look around at different approaches to this 
elsewhere:

You mention Python, which I think has probably the *worst* approach: it 
has official syntax which appears to convey type information, but 
doesn't actually provide any guarantees if you forget to run an external 
tool. Outside of that tool, the type information is just another type of 
comment, just less clearly so than the annotations understood by tools 
like PhpStan and Psalm in today's PHP.

Another approach is TypeScript, which is essentially a complete language 
in its own right, with JavaScript as a compilation target. As I 
understand it, you can call JS code from inside a TS project (and vice 
versa, once the TS is transpiled), but that won't always be seamless, so 
the two languages will tend to end up with separate ecosystems of 
libraries and tooling. Implementing a new language also takes time, and 
ultimately money - in this case, Microsoft's money.

A similar project, closer to PHP's heart, is Hack; the main difference 
being that rather than transpiling to PHP, it initially aimed to compile 
both languages to a common bytecode, to be executed in a shared VM. 
However, it turns out that as well as *adding* features on top of PHP, 
it was necessary for Hack to *remove* features of PHP that weren't 
compatible with a static typing system, and eventually the 
interoperability was dropped altogether. It also has money behind it, in 
this case from Facebook.

Dart, which was written completely from scratch (the money this time is 
Google's), has a type system checked *mostly* at compile-time, but with 
certain run-time assertions inserted where the compiler can't prove 
soundness. The approach seems appealing, but PHP would probably end up 
with a lot of such cases - all the features that the Hack team decided 
to remove - leading to poor performance and confusing developer experience.

I don't have a conclusion to this e-mail, I just thought I'd throw out 
these thoughts.

Regards,

-- 
Rowan Tommins
[IMSoP]