Static analysis metadata formal specification #4210
Replies: 4 comments 1 reply
-
Hi, thank you for opening this, but I don't think there's any real need for this, the current status quo is good enough. I also can't stand participating in any "technical standards committee". I tried participating in PSR-5, but it wasn't my cup of tea. I also believe that @muglug's stance on this is "let's wait at least 6 months after PHP 8 is in the hands of developers using it and see if some standard emerges from practical use". |
Beta Was this translation helpful? Give feedback.
-
Please don't take this the wrong way, but this has implications downstream. I'm pretty sure we would have had support for advanced phpdoc for tools like phpstorm for a while now if PSR-5 had been published. It might have lessened the need for Standard are great to make the rest of the community follow your innovations! |
Beta Was this translation helpful? Give feedback.
-
Yeah, anyone could participate in PSR-5 and take it over the finish line, but it doesn't have to be me :) I'm working on and improving PHPStan here, I can't bear more responsibilites than that. |
Beta Was this translation helpful? Give feedback.
-
I’m on the same general page as @ondrejmirtes. Nobody wants total incompatibility, and the main issue is and will always be the time it takes PhpStorm to support community standards. For example, PhpStorm is closed source, so it will always trail open-source tools. The latest release shows that they do have the capability to support metadata used by the existing community, but it also shows they also really like to invent their own. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I would like to open a discussion about the possibility of a formal specification for metadata that static analysis tools can use.
Let me state that I'm not suggesting that phpstan would bear that responsibility, but a discussion here might be a good place to start.
Metadata
Static analysis tools use certain metadata that developers provide to correctly interpret the code. Practical use-cases of metadata are non-native typehints, mutablity information or assertions. Currently metadata is generally provided through phpdocs, but with PHP8 Attributes can also be used (when supported by the tools). Alternatively, metadata can also be be provided from another context (i.e. .phpstorm.meta.php).
Formal specification
A formal specification would improve interoperability between different tools and also set a precedent for future features to follow a certain agreed-upon guideline. This will allow developers to maintain one singular method and syntax of providing metadata, without worrying about different syntax for different tools. This would not force tools to implement everything defined in the specification, since it can also choose ignore certain metadata (in the same way that
psalm-assert
is not interpreted by phpstan)Collaboration
Historically, phpstan and psalm have done a great job at being compatible (i.e. phpstan correctly interprets phpdocs prefixed with
@psalm-
and vice versa). Since the latest release, PHPStorm has also added support for phpstan and psalm analysis. Other IDEs may use psalm's language server to support analysis. A great deal of interoperability has already been achieved through a shared sense of responsibility of each individual tool maintainer. This has led to a stable informal standard, while leaving room for additions and deviations.The informality of this standard, however, can lead to certain features being supported for the sake of being compatible, without a proper discussion between the tools about the pros and cons (example: https://psalm.dev/articles/php-8-attributes). Tools may also want to wait for an informal standard to naturally emerge before implementing new features. We've seen this with PHPStorm for example, where they held off on implementing template annotations for quite some time.
A formal specification might increase adaptation for tools that do not currently support the informal standard. It can also improve visibility and adaptation of static analysis tools towards end-users (developers). In addition, it can be a stimulus for tool maintainers to come together and discuss potential specifications for future features, before implementing it in their own preferred syntax.
Discussion
I would love to hear everyone's thoughts on this, especially those of tool maintainers like @ondrejmirtes and @muglug. I'm not necessarily advocating that a formal specification is the way to go, but I do think it should be considered and discussed. If there is indeed a case to be made for a formal specification, then perhaps PHP-FIG could even play a role there.
Beta Was this translation helpful? Give feedback.
All reactions