Hey all Am 12.06.25 um 23:04 schrieb Jaap van Otterdijk:
Hi,I think the key players here would be the SA tools and JetBrains (IDE,which is an SA tool). If we can get them together for a working group, I think that would be very valuable. I agree that having those in a working group would be great. But from my previous attempts of restarting PSR-5 and PSR-19 I learned that it was very hard to get them on board. I spend quite some energy to get that done. Maybe I did it the wrong way, but fact is, I failed. So this time when we start something new. I would rather not include them and go our own way. To set a standard, and when there is one, they might be willing to implement it as it is already defined. As far as I have seen until now. They didn't respond to the tooth's on Mastodon either.
I do agree with Jaap here. Having people from SA tools in the working group would be great. But not having them would not render the working group useless. Having a group of people maintaining a registry of attributes will already help and improve things. Especially when the group has a backing by a known and respected entity.
SA (or depending on the usecase other) tools in the end "only" need to implement the logic for handling the attributes.
Attributes themselfs do not really need an implementation as they can exist without being defined in code as far as I know. So setting a standard written in documents would already be a step. And for most static analysis tools they wouldn't even matter to exist as real libraries. As most tools are not loading the code they analyse into the php engine. That would make it more than static analysis. And eventually even break the application doing the analysis. So for me, a structure of documents and a process to add more attributes to the registry would be sufficent. phpDocumentor would never include a library to do anything with the attributes. Maybe only to convert them into reflection like structures. The same would apply for phpstan and psalm. The projects using the attributes might have a need for a library to avoid conflicts with other projects using the same attributes at runtime.
IMO we should still implement the attributes to make them available for those that want to use it - and if only for autocompletion in IDEs
I do see some separation between the attributes that have a runtime meaning and those that only have a meta-data function, like the ones implemented by jetbrains. The only reason to have them as a library would be to make it easier for end users to type them in their code. So they don't have to search for the documentation, like you would need right now to see how to define a callable in docblocks.
See above... :-) So all in all:I did not hear anyone saying that it is a bad idea which implies that the idea has some merits.
We have 4 people that are willing to form an initial Working Group (Juliette, Jaap, Vincent and myself), one of which (Vincent) offered to be the CC sponsor. Per the bylaws that right now would not be sufficient for a full working group but definitely for a limited Working Group
As the scope will definitely evolve over time and is not expected to be actually finished at one point this sounds more like it fits the PER process.
The proposal seems to be to define and maintain a set of attributes that are relevant for more than one single tool so that different tools can use and rely upon a defined set of attributes and users do not need to use several similar attributes with the same meaning for different tools. The expected outcome is a meta-document listing the attributes, possible parameters to them and a usage for each of them. In addition a package will be distributed that contains implementations for these attributes to support usage in code or auto-complete.
Any additions to this? Any Objections?
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/php-fig/5343e14b-7c1a-4eef-adab-34d909b012a7%40heigl.org.
OpenPGP_signature.asc
Description: OpenPGP digital signature
