On Mon, Jun 16, 2025, 10:07 AM 'Andreas Heigl' via PHP Framework Interoperability Group <php-fig@googlegroups.com> wrote:
> Hey Korvin > > Am 16.06.25 um 18:27 schrieb Korvin Szanto: > > On Sun, Jun 15, 2025 at 10:29 PM 'Andreas Heigl' via PHP Framework > > Interoperability Group <php-fig@googlegroups.com> wrote: > > > > 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? > > 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? > > Cheers > > Andreas > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andr...@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 | > +---------------------------------------------------------------------+ > > -- > 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/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 -- 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/CANeXGWV0VQrCCS%3DkAb15EcLW4yF2N7M4MEUB02g%2BH34qBF%3Dihw%40mail.gmail.com.
