Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119460
MIME-Version: 1.0
References: <CABAhh3HfPOdsC6RJo2O6TCH1L09Zv4chfQg=UbuV1rNROSZJ4g@mail.gmail.com>
 <CAJpLVh2LbTFL9PYfiehtXfSerP2_Fr65o-761kgCbOXypoiHgw@mail.gmail.com>
In-Reply-To: <CAJpLVh2LbTFL9PYfiehtXfSerP2_Fr65o-761kgCbOXypoiHgw@mail.gmail.com>
Date: Fri, 3 Feb 2023 13:38:31 -0300
Message-ID: <CAAwFBqrqDNQEo1Dncfn8mF5ujiLB2h7RNR3Dfz42J_gGV-c5kQ@mail.gmail.com>
To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>
Cc: someniatko <someniatko@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000076b1a405f3ce50d3"
Subject: Re: [PHP-DEV] Official Preprocessor
From: flaviohbatista@gmail.com (=?UTF-8?Q?Fl=C3=A1vio_Heleno?=)

--00000000000076b1a405f3ce50d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 3, 2023 at 6:19 AM Olle H=C3=A4rstedt <olleharstedt@gmail.com> =
wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Why not follow the steps of other projects that have been created
independently from the core and,
at some point, gained enough support/traction that were incorporated into
it?

--00000000000076b1a405f3ce50d3--