2023-02-03 17:38 GMT+01:00, Flávio Heleno <flaviohbati...@gmail.com>: > On Fri, Feb 3, 2023 at 6:19 AM Olle Härstedt <olleharst...@gmail.com> > wrote: > >> 2023-02-02 15:19 GMT+01:00, someniatko <somenia...@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?
You'd have to rewrite Psalm or Phpstan in C if you want it to be part of php-src. Or write a completely new project. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
