Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119456
MIME-Version: 1.0
In-Reply-To: <CABAhh3HfPOdsC6RJo2O6TCH1L09Zv4chfQg=UbuV1rNROSZJ4g@mail.gmail.com>
References: <CABAhh3HfPOdsC6RJo2O6TCH1L09Zv4chfQg=UbuV1rNROSZJ4g@mail.gmail.com>
Date: Fri, 3 Feb 2023 10:18:54 +0100
Message-ID: <CAJpLVh2LbTFL9PYfiehtXfSerP2_Fr65o-761kgCbOXypoiHgw@mail.gmail.com>
To: someniatko <someniatko@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Official Preprocessor
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2023-02-02 15:19 GMT+01:00, someniatko <someniatko@gmail.com>:
> Hi Internals
>
> The main gist:
> --------------
>
> 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.
>
> The reasoning:
> --------------
>
> You all know there are a lot of problems with the language, especially
> large gaps with the current type system, which have large community
> demand to overcome, but still cannot be solved due to the paradigm
> chosen by PHP. And the paradigm is to be statically typed (to some
> extent), but dynamically checked language, which limits the number of
> available options due to performance reasons.
>
> The introduction of static types have gradually eliminated the need of
> using external means of communicating the types (phpdoc @param and
> @return annotations), replacing them with native language constructs,
> making the language more expressive and enterprise-ready. However,
> there are a lot of things still missing, like types of arrays,
> including lists, hash-maps and structure-like arrays, and of course
> generic classes and functions. These are still covered nowadays with
> external means like phpdoc annotations and static analysers / type
> checkers to validate them. This leaves PHP in the odd mixture of
> native types and externally validated annotations via comments.
>
> Paradigm of a dynamically checked language also leaves out the problem
> of type-checking before running the code. Even though the types are
> defined statically, you still have to physically run the code, with
> all possible execution paths, to catch a type error. To avoid that you
> still would have to use an external typechecker / static analyser,
> even if PHP could cover 100% of type demand natively.
>
> Python solves this problem nicely I think. It is dynamically typed,
> but it allows a special syntax for static types and also has a
> separate static type checker. I think this is really a good approach
> and it would be great if PHP followed this path for the beginning, but
> we have what we have already.
>
> There were attempts to create preprocessors for PHP (like PHP++ IIRC),
> which allowed features like generics, but they did not gain enough
> popularity, weren't baked by large enough companies, didn't make their
> way to major IDEs support. I believe the only solution is to make an
> official one.
>
> Therefore, I suggest the following thing:
> 1. Introduce a new #declare directive which will mark the file as
> requiring pre-processing.
> 2. Let PHP introduce special features that only work in such
> "pre-processing required" files, such as typed lists and generics.
> 3. Implement a static type-checker in PHP that will verify those typed
> lists and generics are indeed used in a valid way.

No need to waste resources implementing a new one when we already have
two very competent already: Psalm and Phpstan? Or why is those not
enough for your use-case?

"The greatest enemy to a perfect solution is a good enough solution
already in place." ;)

Olle