As a framework author, an approved PSR proposing a set of interfaces for some attributes would be valuable. It's easy to locate libraries that implement PSRs. The PSR(s), of course, would be for the attributes that have a runtime meaning, like a validator attribute. The PSR would, in effect, be a registry of implementations.
On Thu, Jun 12, 2025 at 12:27 PM Ben Ramsey <[email protected]> wrote: > > On Jun 12, 2025, at 06:42, 'Andreas Heigl' via PHP Framework > Interoperability Group <[email protected]> wrote: > > > > Hey Matteo > > > > Am 12.06.25 um 12:44 schrieb Matteo Beccati: > >> Hey Andreas, > >> I've replied on Mastodon before reading your post here. Why not having > a new "standard" Attributes PER, or am I talking nonsense? > > > > After reading up on the details of the PER I am still hesitant whether > it is the right thing... > > > > To me the PSR and PER are regarding one solution to a problem. The PSR > being "just" one solution, the PER regarding changing solutions, but still > to one problem. > > > > Attributes though can provide different solutions to different problems. > > > > So how would that fit into the problem-space? > > > > I am totally with you that the topic of solving the one problem (there > there currently not being a good, easy and central way to distribute > user-land attributes) should be handled in a PSR (or a PER). > > > > But whether the result is then to go for the PER process or eventually > something totally different - also depending on how the artifacts are > distributed - should probably be the first part that the working group > should figure out. > > > > Also seeing that PSR5 and PSR19 are still in draft mode - when all they > do is - by current standards - define attributes - is not very convincing > to use a PSR or a PER for the process of providing a defied set of > attributes for the masses... > > > > BUt I am looking forward to how others see that! > > > > Cheers > > > > Andreas > > > 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. > > 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. > > Cheers, > Ben > > [^1]: https://www.iana.org/assignments/http-methods/http-methods.xhtml > [^2]: https://www.iana.org/assignments/media-types/media-types.xhtml > [^3]: > https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml > [^4]: https://www.iana.org/assignments/uuid/uuid.xhtml > [^5]: https://github.com/JetBrains/phpstorm-attributes/tree/master > > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/php-fig/6144F529-FD0F-4FD3-B0E7-8D6DA71A4A7F%40benramsey.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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/php-fig/CAK51H8PCwBeMUY2aJ-tHUyF5AUA388Wn6QJe19QJhC6pMgqVyA%40mail.gmail.com.
