Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113687
Message-ID: <E5432D41-2A47-4C3A-B84E-3107A03DC887@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4D6D168B-EF5B-4B60-82DB-5B197B16E97E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 22 Mar 2021 13:15:08 -0400
In-Reply-To: <CAF+90c_Nb_ddDQYB9kaETAeg2vJ5ndFEcczX+7x_4e6qssNqqg@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Nikita Popov <nikita.ppv@gmail.com>
References: <CAF+90c-CEZycXeigN9zqsFyZGMxDWVT_YU6h_OMrvORE_qLk3A@mail.gmail.com>
 <341E78A4-B42C-4C4C-B0C5-A190187D6920@newclarity.net>
 <CAF+90c_Nb_ddDQYB9kaETAeg2vJ5ndFEcczX+7x_4e6qssNqqg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Namespaced in bundled extensions
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_4D6D168B-EF5B-4B60-82DB-5B197B16E97E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Mar 22, 2021, at 5:45 AM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>=20
> On Fri, Mar 19, 2021 at 7:28 PM Mike Schinkel <mike@newclarity.net =
<mailto:mike@newclarity.net>> wrote:
> > On Feb 25, 2021, at 3:26 PM, Nikita Popov <nikita.ppv@gmail.com =
<mailto: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 =
<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.
>=20
> Hi Nikita,
>=20
> 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?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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
>=20
> I'd suggest registration of really generic namespaces would be =
discouraged, but not disallowed.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Is this something you can/will add to your RFC?
>=20
> -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
>=20
> No, I am not willing to add a namespace registry to the RFC.
>=20
> 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.
>=20
> 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=

--Apple-Mail=_4D6D168B-EF5B-4B60-82DB-5B197B16E97E--