Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110718
To: internals@lists.php.net
References: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
Message-ID: <981040f9-afdb-2a55-01c5-1afc2c057193@gmail.com>
Date: Wed, 24 Jun 2020 20:32:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <0771c3ac-53ec-4a7f-a4e9-6ae3c9b1f1f6@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
From: rowan.collins@gmail.com (Rowan Tommins)

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 problem.  To that end, Mark Randall and I have put together a new RFC on the topic


Hi Larry,

Thanks for moving forwards with this. To stretch an analogy, I think 
we're better off picking out the colour scheme for this bikeshed in 
advance, rather than just resolving to buy some paint when we need it. :)


One section that gave me pause reading the RFC was this:

 > A component namespace is “claimed” by the RFC that first uses it. 
Once claimed, that component namespace may only be used only by that RFC 
or future RFCs that extend that one in a natural way.

PHP RFCs tend to describe a change rather than a full feature, and once 
accepted are more a historical record of the change than a living 
reference. Perhaps it would make sense to create an IANA-style 
"registry" of reserved "component namespaces", so that RFCs could add, 
and more rarely amend, entries in a central location.

This doesn't need to be elaborate - just a table on a wiki page 
somewhere, with columns such as name, usage definition, status (e.g. 
unused but reserved for forward/backwards compatibility), and maybe 
notes on naming conventions within the component (use of sub-namespaces, 
suffixes, etc).


One thing the RFC doesn't tackle in detail is what we might call The 
PECL Question: what are the processes when an extension moves from PECL 
to php-src (like ext/sodium) or from php-src to PECL (like ext/mysql)?

For moves into PECL, the RFC says that the component namespace "remains 
reserved". If we were maintaining a registry, this could include links 
to PECL with appropriate status notes.

For moves out of PECL, it's trickier. If we have PECL extensions listed 
on the registry, we could have some way to register them *before* the 
extension is added to core; but I'm not quite sure what that process 
would look like, and what kind of endorsement it would imply of the 
extension.

If we don't do that, what would happen when an extension becomes part of 
core and needs to rename functionality from "Foo\Something" or 
"SomeCorp\Foo\Something" to "PHP\Foo\Something"?

One answer would be to follow the same process as renaming functionality 
already in core - i.e. include the old names as aliases, subject to 
deprecation over a major version cycle. This would help users migrating 
from the PECL extension, but users of "vanilla" php-src might be 
confused why there are two names. Worse, it would defeat part of the 
point of the PHP\* namespace, since php-src would be claiming names 
outside it which could conflict with other projects.

Perhaps a cleaner approach would be to add the extension with only the 
new PHP\*  names, and provide a userland polyfill for users upgrading 
from the PECL extension?


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]