On Fri, Mar 19, 2021 at 7:28 PM Mike Schinkel <m...@newclarity.net> wrote:
> > On Feb 25, 2021, at 3:26 PM, Nikita Popov <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 > > > > 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 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. Regards, Nikita
