> On Jun 12, 2025, at 06:42, 'Andreas Heigl' via PHP Framework Interoperability > Group <php-fig@googlegroups.com> 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 php-fig+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/php-fig/6144F529-FD0F-4FD3-B0E7-8D6DA71A4A7F%40benramsey.com.
signature.asc
Description: Message signed with OpenPGP
