Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113624
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <CAF+90c-CEZycXeigN9zqsFyZGMxDWVT_YU6h_OMrvORE_qLk3A@mail.gmail.com>
Date: Fri, 19 Mar 2021 14:28:20 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <341E78A4-B42C-4C4C-B0C5-A190187D6920@newclarity.net>
References: <CAF+90c-CEZycXeigN9zqsFyZGMxDWVT_YU6h_OMrvORE_qLk3A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Namespaced in bundled extensions
From: mike@newclarity.net (Mike Schinkel)

> On Feb 25, 2021, at 3:26 PM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>=20
> Hi internals,
>=20
> 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:
>=20
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>=20
> 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.=20

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