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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
