Hey Korvin Am 16.06.25 um 19:24 schrieb Korvin Szanto:
On Mon, Jun 16, 2025, 10:07 AM 'Andreas Heigl' via PHP Framework Interoperability Group <[email protected]> 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 <[email protected]> wrote: This is an intriguing idea and I definitely see the value in there beingaregistry, 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 singleattributeneed 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 weneedto 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 attributesintheir composer.json and allow the existing package registry to trackthem?That way project maintainers could provide a package of just their attributes and Composer can manage creating a searchable list of thema-lahttps://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:[email protected] 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 [email protected]. 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.
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.
I know. I am merely looking at the Bylaws and there is some discrepancy in them that shows in this case ;-)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.
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.
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:[email protected] 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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/php-fig/c21a1a4f-d852-49cb-8bf0-77d6363b1b3b%40heigl.org.
OpenPGP_signature.asc
Description: OpenPGP digital signature
