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.
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.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.
The draft meta document will be created by the WorkingGroup, that ... can only start working after the WorkingGroup has been created...I'd like to see some answers to these questions laid out in a draft meta document before we vote on entrance.
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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
