Creating a Registry for community provided Attributes

[Andreas Heigl]

Hey folks.

Ben Ramsey proposed an idea on Mastodon[1] to create a registry that
holds and provides user-space attributes for PHP.

His idea was to start a PSR that defines the registry and the processes
to add, modify and remove attributes from that registry.

Having something like such a registry provided by FIG would allow a much
easier adoption in the PHP-community and by tools than either creating
such a registry by someone else privately (why should they be trusted)
or by one of the bigger framework-projects or company.

To maintain the registry though is probably not something the current
FIG processes are fit, so defining a separate process to maintain such a
registry would be a part of the PSR to define.

What are your thoughts on that?

I would definitely be willing to form or join a Working Group. As would
Jaap van Otterdijk (PHP-Documentor) and Juliet Reinders-Follmer
(PHP-Codesniffer)

Cheers

Andreas

[1]: https://phpc.social/@ramsey/114668940897825391
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:and...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

[Alex Makarov]

Interesting. Any examples of which attributes could be added first and how to structure the catalogue?

--
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/30eff731-5caf-466d-a4de-66204cb9fcf8%40heigl.org.

[Andreas Heigl]

Hey

Am 12.06.25 um 10:46 schrieb Alex Makarov:

> Interesting. Any examples of which attributes could be added first
and how
> to structure the catalogue?

One of the first attributes could be the #[Internal] one.

As of how to structure the catalog... I have so far no clue...

Ideas are highly welcome!

I assume in the end we need one or multiple packages on packagist that
contain the actual code.

But figuring out and proposing an idea on how to actually structure the
catalogue would be the job of the working group 🙂

Cheers

Andreas

[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?


Cheers

On 12/06/2025 10:28, 'Andreas Heigl' via PHP Framework Interoperability

Group wrote:
> Hey folks.
>
> Ben Ramsey proposed an idea on Mastodon[1] to create a registry that
> holds and provides user-space attributes for PHP.
>
> His idea was to start a PSR that defines the registry and the processes
> to add, modify and remove attributes from that registry.
>
> Having something like such a registry provided by FIG would allow a much
> easier adoption in the PHP-community and by tools than either creating
> such a registry by someone else privately (why should they be trusted)
> or by one of the bigger framework-projects or company.
>
> To maintain the registry though is probably not something the current
> FIG processes are fit, so defining a separate process to maintain such a
> registry would be a part of the PSR to define.
>
> What are your thoughts on that?
>
> I would definitely be willing to form or join a Working Group. As would
> Jaap van Otterdijk (PHP-Documentor) and Juliet Reinders-Follmer (PHP-
> Codesniffer)
>
> Cheers
>
> Andreas
>
> [1]: https://phpc.social/@ramsey/114668940897825391

--

Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Andreas Heigl]

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

[Matteo Beccati]

Hi Andreas,

On 12/06/2025 13:42, 'Andreas Heigl' 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.

I see your point. In my view there was only one single broader problem
to solve, which is defining a set of common attributes to improve
interoperability of the most widely used SA/CS/etc PHP tools.

Then the working group would be in charge of defining the evolving list
of common attributes that would benefit the community at large.

> BUt I am looking forward to how others see that!

Likewise!


Cheers

[Vincent de Lau]

On Thursday, June 12, 2025 at 10:29:06 AM UTC+2 Andreas Heigl wrote:

Hey folks.

Ben Ramsey proposed an idea on Mastodon[1] to create a registry that
holds and provides user-space attributes for PHP.

His idea was to start a PSR that defines the registry and the processes
to add, modify and remove attributes from that registry.

Having something like such a registry provided by FIG would allow a much
easier adoption in the PHP-community and by tools than either creating
such a registry by someone else privately (why should they be trusted)
or by one of the bigger framework-projects or company.

This sounds like something that fits well within our mission of interoperability, so I see that this is something that the FIG should facilitate. 

I think the registry should have more of an informational character (yellow pages), than an authoritative one. When certain registrations point to common interest, it could trigger standardizing them in a PSR.

To maintain the registry though is probably not something the current
FIG processes are fit, so defining a separate process to maintain such a
registry would be a part of the PSR to define. 

What are your thoughts on that?

We should explore the options. While we could define the registry and its processes trough the PSR or PER processes, I can also imagine that we create a more tailor-made process with a bylaw change.

 

I would definitely be willing to form or join a Working Group. As would
Jaap van Otterdijk (PHP-Documentor) and Juliet Reinders-Follmer
(PHP-Codesniffer) 

I'd like to join this Working Group. If needed, I'm also willing to be the CC Sponsor.

--

Regards,

Vincent de Lau

[Larry Garfield]

On Thu, Jun 12, 2025, at 3:28 AM, 'Andreas Heigl' via PHP Framework Interoperability Group wrote:
> Hey folks.
>
> Ben Ramsey proposed an idea on Mastodon[1] to create a registry that
> holds and provides user-space attributes for PHP.
>
> His idea was to start a PSR that defines the registry and the processes
> to add, modify and remove attributes from that registry.
>
> Having something like such a registry provided by FIG would allow a much
> easier adoption in the PHP-community and by tools than either creating
> such a registry by someone else privately (why should they be trusted)
> or by one of the bigger framework-projects or company.
>
> To maintain the registry though is probably not something the current
> FIG processes are fit, so defining a separate process to maintain such a
> registry would be a part of the PSR to define.
>
> What are your thoughts on that?
>
> I would definitely be willing to form or join a Working Group. As would
> Jaap van Otterdijk (PHP-Documentor) and Juliet Reinders-Follmer
> (PHP-Codesniffer)
>
> Cheers
>
> Andreas
>
> [1]: https://phpc.social/@ramsey/114668940897825391

The way to do this isn't a PSR, but a PER. PER's were set up for exactly this sort of use case. I would be in favor. The question is, would anyone actually use them?

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.

--Larry Garfield

[Ben Ramsey]

> On Jun 12, 2025, at 06:42, 'Andreas Heigl' via PHP Framework Interoperability Group <php...@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

[Larry Garfield]

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

[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

--
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.

[Jaap van Otterdijk]

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:

[Eric Fortmeyer]

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.

--
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/6144F529-FD0F-4FD3-B0E7-8D6DA71A4A7F%40benramsey.com.

[Andreas Heigl]

Hey all

Am 12.06.25 um 23:04 schrieb Jaap van Otterdijk:

> 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.

I do agree with Jaap here. Having people from SA tools in the working
group would be great. But not having them would not render the working
group useless. Having a group of people maintaining a registry of
attributes will already help and improve things. Especially when the
group has a backing by a known and respected entity.

SA (or depending on the usecase other) tools in the end "only" need to
implement the logic for handling the attributes.

>
> 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.

IMO we should still implement the attributes to make them available for
those that want to use it - and if only for autocompletion in IDEs

>
> 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.

See above... :-)

So all in all:

I did not hear anyone saying that it is a bad idea which implies that
the idea has some merits.

We have 4 people that are willing to form an initial Working Group
(Juliette, Jaap, Vincent and myself), one of which (Vincent) offered to
be the CC sponsor. Per the bylaws that right now would not be sufficient
for a full working group but definitely for a limited Working Group

As the scope will definitely evolve over time and is not expected to be
actually finished at one point this sounds more like it fits the PER
process.

The proposal seems to be to define and maintain a set of attributes that
are relevant for more than one single tool so that different tools can
use and rely upon a defined set of attributes and users do not need to
use several similar attributes with the same meaning for different
tools. The expected outcome is a meta-document listing the attributes,
possible parameters to them and a usage for each of them. In addition a
package will be distributed that contains implementations for these
attributes to support usage in code or auto-complete.

Any additions to this? Any Objections?

[Larry Garfield]

On Fri, Jun 13, 2025, at 6:33 AM, 'Andreas Heigl' via PHP Framework Interoperability Group wrote:


> So all in all:
>
> I did not hear anyone saying that it is a bad idea which implies that
> the idea has some merits.
>
> We have 4 people that are willing to form an initial Working Group
> (Juliette, Jaap, Vincent and myself), one of which (Vincent) offered to
> be the CC sponsor. Per the bylaws that right now would not be sufficient
> for a full working group but definitely for a limited Working Group
>
> As the scope will definitely evolve over time and is not expected to be
> actually finished at one point this sounds more like it fits the PER
> process.
>
> The proposal seems to be to define and maintain a set of attributes that
> are relevant for more than one single tool so that different tools can
> use and rely upon a defined set of attributes and users do not need to
> use several similar attributes with the same meaning for different
> tools. The expected outcome is a meta-document listing the attributes,
> possible parameters to them and a usage for each of them. In addition a
> package will be distributed that contains implementations for these
> attributes to support usage in code or auto-complete.
>
> Any additions to this? Any Objections?
>
> Cheers
>
> Andreas

I want to reiterate my earlier point:

A PER whose artifact is a markdown file:

* Pure - Indicates a function with no side effects.
* Internal - Indicates a function that should not be used outside this library

is, IMO, unuseful and potentially even counter productive, and I would not support or participate in it.

A PER whose artifact is a repository with the following in it:

namespace Fig\Attributes;

// Indicates a function with no side effects.
#[Attribute]
class Pure {}

// Indicates a function that should not be used outside this library
#[Attribute]
class Internal {}

I believe would be useful, and I would support it and be interested in joining it.

(Naturally some attributes will also have parameters, some not, that's a case by case to figure out later.)

--Larry Garfield

[Andreas Heigl]

Hey Larry.

Am 13.06.25 um 15:56 schrieb Larry Garfield:

> On Fri, Jun 13, 2025, at 6:33 AM, 'Andreas Heigl' via PHP Framework Interoperability Group wrote:
>
>
>> So all in all:
>>

[snip]

>> The expected outcome is a meta-document listing the attributes,
>> possible parameters to them and a usage for each of them. In addition a
>> package will be distributed that contains implementations for these
>> attributes to support usage in code or auto-complete.
>>
>> Any additions to this? Any Objections?
>>
>> Cheers
>>
>> Andreas
>
> I want to reiterate my earlier point:
>
> A PER whose artifact is a markdown file:
>
> * Pure - Indicates a function with no side effects.
> * Internal - Indicates a function that should not be used outside this library
>
> is, IMO, unuseful and potentially even counter productive, and I would not support or participate in it.
>
> A PER whose artifact is a repository with the following in it:
>
> namespace Fig\Attributes;
>
> // Indicates a function with no side effects.
> #[Attribute]
> class Pure {}
>
> // Indicates a function that should not be used outside this library
> #[Attribute]
> class Internal {}
>
> I believe would be useful, and I would support it and be interested in joining it.
>
> (Naturally some attributes will also have parameters, some not, that's a case by case to figure out later.)

To reiterate my previous point ;-) :

The expected outcome is a meta-document *AND* a package with
implementations of the actual attributes.

IMO it makes no sense whatsoever to only have the meta-document and no
implementation.

But it also doesn't make sense to only have the pasckage and no overview.

Whether the meta-document is autogenerated from the package or manually
crafted is then up to the working group (I strongly suggest to have that
autogenerated!)

The order was not meant as an order of importance! IMO *both* are important!

[Larry Garfield]

Ah, that was unclear, and it sounded like some folks were advocating for just the markdown file (registry). I'm fine with generating a markdown file off of docblocks or whatever, as long as there is a code package.

In that case, I volunteer as tribute!

--Larry Garfield

[Andreas Heigl]

Hey all

Am 13.06.25 um 13:33 schrieb 'Andreas Heigl' via PHP Framework
Interoperability Group:
[snip]

>
> So all in all:
>
> I did not hear anyone saying that it is a bad idea which implies that
> the idea has some merits.
>
> We have 4 people that are willing to form an initial Working Group
> (Juliette, Jaap, Vincent and myself), one of which (Vincent) offered to
> be the CC sponsor. Per the bylaws that right now would not be sufficient
> for a full working group but definitely for a limited Working Group
>
> As the scope will definitely evolve over time and is not expected to be
> actually finished at one point this sounds more like it fits the PER
> process.
>
> The proposal seems to be to define and maintain a set of attributes that
> are relevant for more than one single tool so that different tools can
> use and rely upon a defined set of attributes and users do not need to
> use several similar attributes with the same meaning for different
> tools. The expected outcome is a meta-document listing the attributes,
> possible parameters to them and a usage for each of them. In addition a
> package will be distributed that contains implementations for these
> attributes to support usage in code or auto-complete.
>
> Any additions to this? Any Objections?
>
> Cheers
>
> Andreas
>

So what would be the next steps?

Is the above information already enough for the editor to call for an
entrance vote?

... After reading the bylaws it looks like there is a chicken and egg
situation though...

> Editors are appointed by the Core Committee

> Working Groups are created by an Entrance Vote of the Core Committee.
The Entrance Vote includes the appointment of an Editor

> The Editor (for a Limited Working Group) or Sponsor (for a Full
Working Group) may then call for an Entrance Vote of the Core Committee
to enquire whether the Core Committee is generally interested in
maintaining a PER for the proposed subject, even if they disagree with
the details of the proposal.

Anyone able to shed some light here would be appreciated...

Do we (Jaap, Juliette, Vincent, Larry, myself and whoever else is
interested) now just form an informal group to discuss things off-list
or is that something that needs to happen *after* creating a WorkingGroup?

I mean we can for sure discuss things separately but I'd rather use
"official" means for that so that the process is as transparent to
anyone interested as possible.

Looking forward to some purely process-related feedback here.

[Korvin Szanto]

--
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/0cb8632e-364d-4de0-84a3-10765a24b742%40heigl.org.

This is an intriguing idea and I definitely see the value in there being a registry, but I struggle to imagine how it'd work in practice if it's successful. 

How would we:

- package this via composer? Would anyone wanting to use a single attribute need to download the entire corpus? What if we are successful and end up with megabytes of attributes?

- decide which attributes are valuable and which are not? Wouldn't we need to accept all attributes to avoid bias and prevent blocking people in the wild trying to build new things?

- deal with backwards compatibility? Wouldn't it be likely that these attributes need to change over time?

- deal with naming collisions? Are we going to namespace things further than `\Per\Attribute`? What if a project changes its name or namespace?

- handle deprecations? Are we appointing someone from the originating project to manage the lifecycle or are we expecting the editor to be the arbiter?

Given that PHP already has a widely available and trusted registry in Composer, wouldn't it be better for packages to declare their attributes in their composer.json and allow the existing package registry to track them? That way project maintainers could provide a package of just their attributes and Composer can manage creating a searchable list of them a-la https://packagist.org/extensions.

I'd like to see some answers to these questions laid out in a draft meta document before we vote on entrance.

Best,

Korvin

 

[Andreas Heigl]

Hey Korvin

Am 16.06.25 um 18:27 schrieb Korvin Szanto:

These are all questions that the WorkingGroup needs and will tackle.
Having answers to them right now would somehow obsolete the necessity
for a WorkingGroup.

What *I* can imagine right now (and this will for sure be something that
we will discuss in the WorkingGroup) is that there is little value in
not providing the attributes as composer-package.

whether that is one big one (which I find rather problematic - at least
as the sole way of distribution) or several smaller ones is to be
discussed. Though I do think that having them all in one repository does
make sense. But we can easily create several packages as well as
meta-packages from that one repo.

How to decide which attributes are valuable will definitely be one of
the challenges of the working group. For me personally an attribute has
value when it is used by more than one tool or library. As that is the
point where the interoperability comes into play. BUt how to exactly
decide upon that - especially with new attributes - will be up to the
working group.

Naming colissions I assume to not really happen. The naming will be
something like `Per\Attribute\Subdivision\AttributeName` I do not see
any issues with projects changing names as I do not see any
project-names within the FIGs naming-space. When an attribute has value
for several tools it will be named tool-agnostic. So I doubt that we
will have something like `Per\Attribute\Phpstan\Internal` but instead
something like `Per\Attribute\[Docblock\]Internal` which can then be
used by PHPStan, Psalm, PHPDocumentor, PHP-CS-Fixer and PHPCS, to name a
few, without PHPStan being somehow elevated in the naming.

As there will not be any project-specific attributes part of the
packages there is not really an issue with deprecations or BC problems
that we can not solve within our WorkingGroup.

Perhaps the most interesting thing is that we do not plan to have a
registry of attributes defined elsewhere but to define interoperable
attributes ourselves. Based on recommendations from the outside perhaps
(or most certainly) but those are "our" attributes.

>
> Given that PHP already has a widely available and trusted registry in
> Composer, wouldn't it be better for packages to declare their attributes in
> their composer.json and allow the existing package registry to track them?
> That way project maintainers could provide a package of just their
> attributes and Composer can manage creating a searchable list of them a-la
> https://packagist.org/extensions.

This is an idea for attributes that are based on a specific package.
What we are envisioning though is one or several packages solely with
interoperable attribute-definitions. It might be an idea to work on with
the packagist and composer team to make attributes easier discoverable
via packagist. But that is IMO a separate topic. The WorkingGroup can
start this discussion or act as one counterpart for discussions around
that idea (that I personally like) but it is not the main thing that we
are thinking about right now.

>
> I'd like to see some answers to these questions laid out in a draft meta
> document before we vote on entrance.

The draft meta document will be created by the WorkingGroup, that ...
can only start working after the WorkingGroup has been created...

This is one of the things that I would loveto get some clarity on from
official FIG side...

Does that answer some of your questions?

[Korvin Szanto]

--
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/89be5677-5855-4286-8820-0c973ea47636%40heigl.org.

This does help answer some of my questions, thank you. Though I think it might be harder to define what is used by multiple projects and what isn't, for example if I write a competing ORM and use doctrine attributes as a base. These questions and potential answers would be a great start to a meta document along with a scope that lays out what is intended to be included and what is not.

A working group isn’t picked by the committee and doesn't need to wait for entrance approval. Typically a newly proposed PSR/PER already has an editor, sponsor, working group, and a rough draft of what is being proposed for people to vote on. It might help to look at examples of past entrance votes by searching the google group for "[ENTRANCE]".

For me at least it will be hard to vote yes on this without a document that describes what we're voting for.

Thanks for the quick reply and the clarification,

Korvin

[Andreas Heigl]

Hey Korvin

Am 16.06.25 um 19:24 schrieb Korvin Szanto:

When you write a competing ORM and use the Doctrine Attributes, then you
relly upon them and this has nothing to do with the PER we are talking
about here.

If though you (as the writer of the competing ORM) think that it would
be great to use something interoperable then you can challenge the folks
from Doctrine whether it makes sense to use something interoperable and
together with them challenge the WorkingGroup. (This is not the final
proposed workflow but my personal idea after 2 minutes of thinking!
There possibly might be room for improvement :-D)

It does not make sense to take over maintenance of a projects set of
attributes that is only thought to be used within that project. And I
would argue that a different ORM would use the exact same attributes as
the docrine ORM. And if so I'D ask why I then should not use Doctrine.

Like with interfaces there are some that are part of a frmaework or a
library and need to stay within their scope and there are others that
make sense to be maintained by an independent body. Just because
something is an attribute does not mean it makes sense to be maintained
by a FIG-WorkingGroup. The final say on this will be with the
WorkingGroup or possibly - if they are unsure - with the CoreCommitee.

>
> A working group isn’t picked by the committee and doesn't need to wait for
> entrance approval. Typically a newly proposed PSR/PER already has an
> editor, sponsor, working group, and a rough draft of what is being proposed
> for people to vote on. It might help to look at examples of past entrance
> votes by searching the google group for "[ENTRANCE]".

I know. I am merely looking at the Bylaws and there is some discrepancy
in them that shows in this case ;-)

>
> For me at least it will be hard to vote yes on this without a document that
> describes what we're voting for.

The bylaws by the way also specifically say that "The proposal is not
required to be fully developed at this point[...]. At minimum, it must
include a statement of the problem to be solved, the scope of the PER
Working Group, and the artifacts it expects to produce." - which has by
now been posted several times here.

After that the bylaws speak of an "Entrance Vote of the Core Committee

to enquire whether the Core Committee is generally interested in
maintaining a PER for the proposed subject, even if they disagree with
the details of the proposal."

In essence the vote is whether the FIG wants to create a WorkingGroup
that maintains a registry of interoperable attributes - where
interoperable is to be defined in more detail by the WorkingGroup. As is
"registry". Personally I see "registry" as one or more composer packages
along with one or more Meta-Documents but that is in the end up to the
WorkingGroup.

[Larry Garfield]

On Mon, Jun 16, 2025, at 12:41 PM, 'Andreas Heigl' via PHP Framework Interoperability Group wrote:

>> For me at least it will be hard to vote yes on this without a document that
>> describes what we're voting for.
>
> The bylaws by the way also specifically say that "The proposal is not
> required to be fully developed at this point[...]. At minimum, it must
> include a statement of the problem to be solved, the scope of the PER
> Working Group, and the artifacts it expects to produce." - which has by
> now been posted several times here.
>
> After that the bylaws speak of an "Entrance Vote of the Core Committee
> to enquire whether the Core Committee is generally interested in
> maintaining a PER for the proposed subject, even if they disagree with
> the details of the proposal."
>
> In essence the vote is whether the FIG wants to create a WorkingGroup
> that maintains a registry of interoperable attributes - where
> interoperable is to be defined in more detail by the WorkingGroup. As is
> "registry". Personally I see "registry" as one or more composer packages
> along with one or more Meta-Documents but that is in the end up to the
> WorkingGroup.

Next step would be for the Editor/Sponsor to put together a PR against the fig-standards repository, including a metadoc that contains the mission statement for the WG, its members, and what it expects to produce (one or more composer packages that contain attributes). There's no real spec to include here at this point. Then that can be formally proposed to the CC.

Once it's approved, we can spin up a Discord channel for the WG to hash out the details.

--Larry Garfield

[Andreas Heigl]

So then...

Am 16.06.25 um 19:57 schrieb Larry Garfield:
[snip]

>
> Next step would be for the Editor/Sponsor to put together a PR against the fig-standards repository, including a metadoc that contains the mission statement for the WG, its members, and what it expects to produce (one or more composer packages that contain attributes). There's no real spec to include here at this point. Then that can be formally proposed to the CC.

Here we go! https://github.com/php-fig/fig-standards/pull/1331