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+unsubscr...@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/CAJXdS0FpbHBf55z-oQu_hxBq7wPqCu0kVQ%3DF2S7VgzxE%3DC%2Bkzg%40mail.gmail.com.
