[RFC] Namespaced in bundled extensions View as Markdown

I'd love to have some more feedback on this RFC before opening voting.
There has been a lot of discussion beforehand, but only a couple responses
to this RFC...

I very much like this pragmatic approach, which also matches most of the
already existing extensions using namespaces. Thank you!

--
Christoph M. Becker

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:

https://wiki.php.net/rfc/namespaces_in_bundled_extensions

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.

Both of the namespacing RFCs have been announced for over 3 weeks and I don't think I've
seen any new discussion since then.
Are any updates planned? When will voting on the namespacing RFC(s) start?
(I had some stdlib RFCs/RFC ideas I was postponing since February to avoid interfering with the namespacing discussion)

I'd love to have some more feedback on this RFC before opening voting. There has been a lot of discussion beforehand, but only a couple responses to this RFC...

I didn't plan to suggest changing the direction of the RFC, so I didn't have much to say.
I guess it's an improvement from a user perspective and that splitting core/PECL/composer namespacing wouldn't make much sense,
especially with the ability to polyfill most core functionality in composer packages (especially with PHP providing FFI, low level socket/stream code, etc).

For something like https://wiki.php.net/rfc/cachediterable I'd still be faced with the namespacing choice among multiple options if this passed,
but choosing names for everything is out of the scope of this RFC.

• iterable\CachedIterable would be the most likely, although it's also in some ways a datastructure
• For SPL, e.g. for a new Map type or existing classes such as SplObjectStorage,
  there'd still be a number of different names such as DataStructure\Map or Collections\Map (DS is already used by an independent PECL)
• "When adding new symbols to existing extensions, it is more important to be consistent with existing symbols than to follow the namespacing guidelines."
  raises the question of whether existing iterables should be aliased to a namespace around the same time
• 5 years from now we may have a different group of active voters, so if this passed with low voting turnout
  I'm not sure if there'd still be arguments over the choice to use/not use a namespace.

For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable it'd help if there was known community consensus (i.e. the vote on namespaces in bundled extensions finished)

I didn't notice before, but I assume you'd still planned to summarize feedback so far in a discussion section before opening https://wiki.php.net/rfc/namespaces_in_bundled_extensions

For https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
use Array; and use String; are currently syntax errors for the unexpected token "array".
That could be fixed in the parser by adding a special case for namespace uses,
especially now that T_NAMESPACED_NAME now allows string\contains to be used without a syntax error.

One possible concern is what would happen if PHP implemented new functionality that overlapped with a fairly well-known PECL/Composer package.
E.g. if there was already a FooDB\Client in a composer/PECL package, and an independent implementation was later added to php-src,
there'd potentially be conflicting names.
Being able to implement PHP\FooDB\Client would avoid that ambiguity

• Then again, other programming languages such as Python have no issue with that, so never mind.
  FooDBClient\ or Foo\ or something could probably be used.

All symbols defined in the extension should be part of the top-level namespace or a sub-namespace.

This should be clarified - do you mean the extension's top-level namespace (e.g. OpenSSL) instead of the global namespace? I assume the former.

Regards,
Tyson

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.

I wonder how long it would take for somebody to submit a PR which
registers several millions of arbitrary namespaces.

A good bit longer than it would take to deny the PR and not merge it, I'm sure.

So I guess to be explicit, one namespace per PR.

-Mike

Hi internals,

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:

https://wiki.php.net/rfc/namespaces_in_bundled_extensions https://wiki.php.net/rfc/namespaces_in_bundled_extensions

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.

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

No, I am not willing to add a namespace registry to the RFC.

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.

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