Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110720
User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345
Mime-Version: 1.0
Message-ID: <a4e7b7ac-afec-4d78-a5fc-62e7586af9c3@www.fastmail.com>
In-Reply-To: <981040f9-afdb-2a55-01c5-1afc2c057193@gmail.com>
References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
 <981040f9-afdb-2a55-01c5-1afc2c057193@gmail.com>
Date: Wed, 24 Jun 2020 18:11:39 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jun 24, 2020, at 2:32 PM, Rowan Tommins wrote:
> On 24/06/2020 01:30, Larry Garfield wrote:
> > * We should never namespace anything ever.
> > * We can namespace things but we need something more concrete than "=
RFCs can namespace things if they feel like it."
> >
> > I can't do much about the former, but the latter is a solvable probl=
em.  To that end, Mark Randall and I have put together a new RFC on the =
topic
>=20
>=20
> Hi Larry,
>=20
> Thanks for moving forwards with this. To stretch an analogy, I think=20=

> we're better off picking out the colour scheme for this bikeshed in=20=

> advance, rather than just resolving to buy some paint when we need it.=
 :)

Ha!  An apt analogy, yes.

> One section that gave me pause reading the RFC was this:
>=20
>  > A component namespace is =E2=80=9Cclaimed=E2=80=9D by the RFC that =
first uses it.=20
> Once claimed, that component namespace may only be used only by that R=
FC=20
> or future RFCs that extend that one in a natural way.
>=20
> PHP RFCs tend to describe a change rather than a full feature, and onc=
e=20
> accepted are more a historical record of the change than a living=20
> reference. Perhaps it would make sense to create an IANA-style=20
> "registry" of reserved "component namespaces", so that RFCs could add,=
=20
> and more rarely amend, entries in a central location.
>=20
> This doesn't need to be elaborate - just a table on a wiki page=20
> somewhere, with columns such as name, usage definition, status (e.g.=20=

> unused but reserved for forward/backwards compatibility), and maybe=20=

> notes on naming conventions within the component (use of sub-namespace=
s,=20
> suffixes, etc).

I didn't want to over-reach, as I am not familiar enough with other Wiki=
 processes etc. to know what the rules would be for establishing such a =
registry.  I agree it's a good idea, though, if someone can suggest work=
able logistics.  A wiki page or a page in docs would both make sense to =
me.

> One thing the RFC doesn't tackle in detail is what we might call The=20=

> PECL Question: what are the processes when an extension moves from PEC=
L=20
> to php-src (like ext/sodium) or from php-src to PECL (like ext/mysql)?=

>=20
> For moves into PECL, the RFC says that the component namespace "remain=
s=20
> reserved". If we were maintaining a registry, this could include links=
=20
> to PECL with appropriate status notes.
>=20
> For moves out of PECL, it's trickier. If we have PECL extensions liste=
d=20
> on the registry, we could have some way to register them *before* the=20=

> extension is added to core; but I'm not quite sure what that process=20=

> would look like, and what kind of endorsement it would imply of the=20=

> extension.
>=20
> If we don't do that, what would happen when an extension becomes part =
of=20
> core and needs to rename functionality from "Foo\Something" or=20
> "SomeCorp\Foo\Something" to "PHP\Foo\Something"?
>=20
> One answer would be to follow the same process as renaming functionali=
ty=20
> already in core - i.e. include the old names as aliases, subject to=20=

> deprecation over a major version cycle. This would help users migratin=
g=20
> from the PECL extension, but users of "vanilla" php-src might be=20
> confused why there are two names. Worse, it would defeat part of the=20=

> point of the PHP\* namespace, since php-src would be claiming names=20=

> outside it which could conflict with other projects.
>=20
> Perhaps a cleaner approach would be to add the extension with only the=
=20
> new PHP\*=C2=A0 names, and provide a userland polyfill for users upgra=
ding=20
> from the PECL extension?

Mark had discussed having a \PHP\Ext\ namespace for extensions.  I deal =
with extensions rarely enough that I don't have a strong opinion on the =
matter.  I'm fine with no Ext segment, but if others feel strongly about=
 having it that's good too.  Whatever is agreeable works for me.  We cou=
ld also pre-reserve a namespace for PECL packages in general to use if t=
hat makes sense to people.

For transitioning in/out, my feeling is:

* On the way in, it's a new feature for php-src so follows the same rule=
s as any other new php-src code.
* User-space polyfills should be a reasonable and straightforward thing =
to do *most* of the time, so that's fine.
* On the way out, the namespace remains reserved for a while so a user-s=
pace polyfill is just as viable.
* These are heuristics, not absolute rules, so if a particular extension=
 really really has need to be different that's OK, and we explicitly giv=
e ourselves wiggle room should that be needed.  The goal here is to make=
 it clear what the default policy is and where the burden of proof is to=
 demonstrate a need to be non-default.

--Larry Garfield