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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/php-fig/52f6a681-014e-444d-ae2e-a4694ab041c7%40app.fastmail.com.
