> On Mar 22, 2021, at 5:45 AM, Nikita Popov <nikita....@gmail.com> wrote: > > On Fri, Mar 19, 2021 at 7:28 PM Mike Schinkel <m...@newclarity.net > <mailto:m...@newclarity.net>> wrote: > > On Feb 25, 2021, at 3:26 PM, Nikita Popov <nikita....@gmail.com > > <mailto:nikita....@gmail.com>> wrote: > > > > Hi internals, > > > > The question of namespaces in the stdlib has been coming up a lot recently, > > so I'd like to present my own stab at resolving this question: > > > > https://wiki.php.net/rfc/namespaces_in_bundled_extensions > > <https://wiki.php.net/rfc/namespaces_in_bundled_extensions> > > > > Relative to a number of previous (declined) proposals, the main difference > > is that I do not propose a top-level "PHP\" vendor namespace, and instead > > recommend the use of "ExtName\", in line with existing practice for > > extensions. I believe this addresses the primary concern with previous > > proposals. > > Hi Nikita, > > Can I request/suggest that if we are going to take this approach that the RFC > also adds an "advisory" registry for namespaces in the form of a Github repo > with parallel README.md and namespaces.json files containing "registered" > namespaces and a link for more information? > > The benefit of such a registry would be to allow people who want to avoid > using a namespace others are already using in public to find the list of > namespaces for code that has been published publicly. Full stop. > > For what I am proposing, the registry would NOT be used to _stop_ people from > using "registered" namespaces. They would be free to do so if they chose to. > The registry would instead be for those who want to ensure their code is most > likely to play nice with anyone else's code. > > The registration process would be as simple as submitting a PR that includes > the requested namespace added to both the README.md and the namespaces.json > file along with a link for more information. > > There would not be any approval process per se other than merging the PR, and > there would not be any "owner" of the registration per se as registration > would merely be a stake in the ground to recommend others not use that same > namespace. > > I'd suggest registration of really generic namespaces would be discouraged, > but not disallowed. > > I envision the link to more information would be a link to a git repo with > either the code or information about the namespace in the README. If after a > namespace is registered we find that other people/organizations are using the > same namespace then the maintainers of the repo could choose to add multiple > links to the same namespace. > > Again, in summary, this list of "registrations" would be to allow people to > easily find out if the namespace they want to use has already been used > publicly by others, and if not to allow them to "register" it for their use. > > If maintainers of the repo discover and PR behavior that is suspect, they > could bring to the internals list to discuss a resolution. But unless and > until that happens, governance of this registry would be as minimal as > possible. > > Is this something you can/will add to your RFC? > > -Mike > P.S. If this existed it would be something PhpStorm (and VSCode) could > probably use to help developers who find namespaces in code to be able to > find out where they can learn more about those namespaces. And later, the > git repo could publish a namespace.json with a lot more information about the > namespace that could help PhpStorm offer even more help to developers. > #justsaying > > No, I am not willing to add a namespace registry to the RFC. > > I do acknowledge that the lack of vendor prefix may make namespace collisions > more likely, although an important mitigating factor here is that that > userland libraries (unlike existing extensions) do typically use a vendor > namespace, and vendor namespaces usually do not collide with component > namespaces.
I appreciate and respect your decision. > I also think that there should be some common courtesy involved in the choice > of namespaces -- if there is some really popular unvendored open-source > library out there that already uses some namespace prefix, we definitely > should consider that in our naming decisions. > > But I don't think this needs any formal process of namespace registration, > which creates unnecessary bureaucracy and misaligned expectations. If your > library is important enough, then people will be aware of the issue. The > converse also holds. But I do want to point out it can be difficult to discover namespaces that may conflict when they are not the main namespace for a popular open-source solution. So it sucks for the developer who wants to use two conflicting "not important enough" libraries. But I do accept that this idea is a no-go in your RFC. -Mike
