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. 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. 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. Jaap(io) Op donderdag 12 juni 2025 om 20:13:42 UTC+2 schreef Navarr Barnier: > I accidentally sent this message with the wrong email, so it was rejected > from the list. Though in essence it is exactly what Larry just said. > > > I'll be honest, I don't quite see the value in a list of user-space > attributes. With PHP namespacing, anyone can create them and while that is > a mess it leads more to common ones that static analysis tools would > utilize perhaps itself being a PER, with the attributes under the fig > namespace so phpstan and psalm and similar tools don't have to support an > infinitely growing number of namespaced attributes, while leaving the root > namespace open for PHP. For example, JetBrains does indeed already have a > library of attributes they support [1] > > A registry would likewise either have duplicate attributes or incentivize > a first-come first-serve system; prone to holding outdated libraries. > > Considering that attributes require a minimal amount of code and a > composer package, I feel this would be best as fig-hosted code rather than > a registry. > > That said, perhaps there is room for both. > > [1]: https://github.com/JetBrains/phpstorm-attributes > > > On Thu, Jun 12, 2025 at 1:47 PM Larry Garfield <la...@garfieldtech.com> > wrote: > >> On Thu, Jun 12, 2025, at 11:27 AM, Ben Ramsey wrote: >> >> > Here’s a little background on how I was thinking about this, though >> > this by no means is how I necessarily think FIG should address this, >> > and from fedi discussion this morning, it sounds like Larry envisioned >> > the PER process as supporting this. >> > >> > When creating an IETF RFC, the RFCs are able establish registries. You >> > might be familiar with the registries for HTTP methods[^1], media >> > types[^2], and status codes[^3]. There are other registries, too, such >> > as for UUID subtypes and namespace IDs[^4]. The pattern for creating a >> > registry from an RFC looks like this: >> > >> > * https://www.rfc-editor.org/rfc/rfc9562#section-7 >> > * https://www.rfc-editor.org/rfc/rfc9110#section-16.1 >> > * https://www.rfc-editor.org/rfc/rfc9110#section-16.2 >> > * https://www.rfc-editor.org/rfc/rfc6838 >> > >> > A PER for PHP attributes would probably work similarly. It can be as >> > light-weight as, “You can submit your attribute for consideration, and >> > as long as it follows these rules, we’ll add it to the registry list, >> > linking off to your documentation” (like how the media types registry >> > works), or it can be more in-depth, and the PER requires a repository >> > that contains all the attributes, which must go through a more >> > stringent review process. >> >> I don't think the former approach (purely a reference list) would work so >> well in practice. A list of "hey, Symfony defines these 30 attributes, >> PHPStan defines these 4, Laravel has these 2, Serde has these 8, etc." >> doesn't really offer much value; none of those attributes are really useful >> unless someone requires the entire package in which they're defined, which >> there's no reason to do unless you're using that package. At which point >> the central list doesn't really help you. >> >> What would be more useful, I think, would be a common repository for >> genuinely broad-usage attributes. Things like #[\Fig\Internal], or >> #[\Fig\Pure], etc. Those anyone could use, and they'd all be the "same" >> attribute with the same meaning for everyone. Attributes that are really >> only useful for one library, like Serde's Field attribute, would not be >> useful. >> >> However, if there were, say, a good standardized \Fig\DictionaryType >> attribute that specified both the key type and value type, that's something >> I could bridge into Serde to replace/supplement the DictionaryField >> attribute I already have. But \Fig\DictionaryType would not have any >> Serde-specific bits. >> >> Similarly for potential common validation definitions. Eg, >> `Fig\String\Regex($pattern)`, which any validation library, serialization >> library, etc. could leverage in addition to its own more robust version if >> desired. >> >> > Anyway, I’m fully on-board with whatever direction this group decides >> > to take. I’d just love to see this exist, so we can standardize around >> > common attributes. `Internal` has already been mentioned as one I’d >> > like to see. JetBrains also provides jetbrains/phpstorm-attributes[^5], >> > some of which would be nice to see standardized. >> >> That seems like a good starting point for ideas, definitely. >> >> --Larry Garfield >> >> -- >> 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+u...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/php-fig/52f6a681-014e-444d-ae2e-a4694ab041c7%40app.fastmail.com >> . >> > -- 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/3108eb2b-9b0d-439d-9222-18640a1d4c50n%40googlegroups.com.
