Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] PHP Namespace Policy »

[RFC] PHP Namespace Policy

php.internals

Mark Randall

6 years ago
Greetings, I would like to re-open the discussion on properly reserving the \PHP namespace for the use of the engine and its core extensions. Rather than seek to demand everything be moved into namespaces, I have instead written this RFC as something that would form a policy guideline for future development of the engine and those extensions which are directly managed by internals. At present, the accepted style is to "fake" a namespace by prefixing symbols with Php. As internals "claims" the top level namespace, this effectively means that all userland code must exist in its own namespace, which is indeed how almost all modern userland code is written, which if anything this proves the benefit of namespacing. In effect, this is both demanding a particular style, while choosing not to use it ourselves. Furthermore, based on the common understanding that a namespace owns and is responsible for all of its descendants, our current arrangement is that _all_ code belongs to PHP and that internals using _any_ namespaces at all could lead to a legitimate collision. Finally, the \PHP namespace itself IS already noted in the documentation to be reserved. https://www.php.net/manual/en/language.namespaces.rationale.php "The Namespace name PHP, and compound names starting with this name (like PHP\Classes) are reserved for internal language use and should not be used in the userspace code." This RFC would formalise that notice, and give notice to internals that the use of \PHP was permitted and encouraged. https://wiki.php.net/rfc/php_namespace_policy
-- Mark Randall

Derick Rethans

6 years ago
Hi Mark, On Wed, 15 Apr 2020, Mark Randall wrote:
> I would like to re-open the discussion on properly reserving the \PHP > namespace for the use of the engine and its core extensions.
I will be voting no against this. The RFC states: By design this RFC does NOT propose moving anything existing into the \PHP namespace at this time, only that the policy is set that it is the preferred mechanism for future development. This will mean that in a future version of PHP, some things will live in a \PHP namespace, and others, such as DateTimeImmutable or Directory do not. We should not be introducing inconsistencies. It also says: \PHP (must be empty except for other namespaces) Which means new additions to PHP 8, such as a potential PhpAttribute, now would have been \PHP\Engine\Attribute, while we already have PhpToken. That is another inconsistency that we don't need. I would potentially be OK with having both \PHP\Token and \PHP\Attribute, as in PHP 8 these engine related classes are being introduced for a first time (as far as I am aware). cheers, Derick
-- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug

Mark Randall

6 years ago
On 15/04/2020 12:23, Derick Rethans wrote:
> This will mean that in a future version of PHP, some things will live in > a \PHP namespace, and others, such as DateTimeImmutable or Directory do > not. We should not be introducing inconsistencies.
It notes that it should be the preferred method for new feature development, and intentionally stops short of requiring it, to provide plenty of room for leeway in cases like this where there is an obvious benefit to keeping features aligned.
> Which means new additions to PHP 8, such as a potential PhpAttribute, > now would have been \PHP\Engine\Attribute, while we already have > PhpToken. That is another inconsistency that we don't need.
I would argue that both these two great new features would benefit from an additional level, unless of course we can guarentee that we would never introduce anything else into PHP called token, or attribute, at which point we are back to square one, a problem which can be almost all together avoided by adding a "feature" specific namespace under \PHP.
-- Mark Randall marandall@php.net

Dan Ackroyd

6 years ago
On Wed, 15 Apr 2020 at 12:21, Mark Randall <markyr@gmail.com> wrote:
> > Rather than seek to demand everything be moved into namespaces, I have > instead written this RFC as something that would form a policy > guideline for future development of the engine and those extensions > which are directly managed by internals.
> https://wiki.php.net/rfc/php_namespace_policy
Hi Mark, Everything is a trade-off. Putting core functions under a namespace makes those core functions harder to use, as people would need to 'use' those functions to make them available in their current namespace. Even assuming the reasons in the RFC are correct, the tradeoff between them and 'making core functions harder to use' does not seem a great tradeoff to make. Another benefit of having core PHP symbols in the root namespace is that it means we can avoid having the discussion of what the namespace naming rules should be. Again, the tradeoff of having to spend time on that discussion of how to name things vs a possible small benefit of having new symbols under a namespace, seems a bad tradeoff. Is there anything you want to add to the RFC to change that view?
> This RFC would establish the protocol for a registry, upon > which internals and core extension authors can, as part of their RFC, ...
This is a direct suggestion of how to slow down productivity from the CIA "Simple sabotage field manual"*: (11) General interference with Organizations and Production (b) Managers and supervisors (13) Multiply the procedures and clearances involved in issuing instructions, pay checks, and so on. See that three people have to approve everything where one would do. Even if you think namespaces might help a little, I don't think introducing a new procedure for RFCs would be worth that cost. cheers Dan Ack * "Simple sabotage field manual" - https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf Note, the CIA still had the name OSS when published.

Mark Randall

6 years ago
On 15/04/2020 12:40, Dan Ackroyd wrote:
> Another benefit of having core PHP symbols in the root namespace is > that it means we can avoid having the discussion of what the namespace > naming rules should be. Again, the tradeoff of having to spend time on > that discussion of how to name things vs a possible small benefit of > having new symbols under a namespace, seems a bad tradeoff.
Dan, I see this being as simple as the RFC author stating that they intend to use a specific namespace such as: \PHP\Tokenizer Followed by updating a wiki page once it's been approved to list the namespace and the RFC which approved it. In that respect it would be no different than arguing over any other name which can already happen. Mark Randall marandall@php.net

Remi Collet

6 years ago
Le 15/04/2020 à 13:21, Mark Randall a écrit :
> Greetings, > > I would like to re-open the discussion on properly reserving the \PHP > namespace for the use of the engine and its core extensions.
What does that mean for PECL extension ? If they have to use another namespace, sorry, but I will vote NO, as this doesn't make any sense Extension (pecl or other) can be include in core later or core extension dropped and move to pecl. I rather think than C ext should use no namespace Remi

Mark Randall

6 years ago
On 15/04/2020 14:20, Remi Collet wrote:
> Le 15/04/2020 à 13:21, Mark Randall a écrit : > Extension (pecl or other) can be include in core later > or core extension dropped and move to pecl.
Quoting the RFC: Once approved, a namespace that is a child of \PHP will remain exclusively for the originally assigned purpose, even if the associated code is moved out of core, unless a 2/3rds vote is held to withdraw that namespace. By design this RFC does NOT propose moving anything existing into the \PHP namespace at this time, nor does it REQUIRE future development uses it, only that the policy is set that it is the preferred mechanism for future development where suitable to do so.

Andrew Faulds

6 years ago
Hi Mark, Mark Randall wrote:
> As internals "claims" the top level namespace, this effectively means > that all userland code must exist in its own namespace, which is > indeed how almost all modern userland code is written, which if > anything this proves the benefit of namespacing.
Yes, post-5.3 PHP internals has essentially claimed the \ namespace for itself by inaction. Is that a bad thing? It makes all new internal functions and classes easy to access.
> In effect, this is both demanding a particular style, while choosing > not to use it ourselves.
Sure, but your proposal would have us essentially be inconsistent about using namespaces, as 99% of internal functions, classes and constants would still be un-namespaced.
> Furthermore, based on the common understanding that a namespace owns > and is responsible for all of its descendants, our current arrangement > is that _all_ code belongs to PHP and that internals using _any_ > namespaces at all could lead to a legitimate collision.
This feels like reaching to me. Yes, there is an established convention for namespaces in userland, but as you already acknowledged, internals isn't following that convention. I don't think anyone who has some familiarity with PHP would notice all internals stuff is in \ and conclude that PHP 8.2 is going to add classes beginning with \Symfony\ or something — after all, wouldn't that mean *all* projects with a history predating PHP 5.3 also own all namespaces? I think this proposal would create more inconsistency (99% of classes in \, some classes in \PHP\) for negligible benefit. Regards, Andrea

Mark Randall

6 years ago
On 15/04/2020 12:21, Mark Randall wrote:
> https://wiki.php.net/rfc/php_namespace_policy
Just an update in light of the two different RFCs. Having chatted with the other RFC authors in R11, rather than racing to see who can get their RFC to vote first, it seems like there's room for both. Vote 1 would be the other RFC which would be something along the lines of: "Mandate the use of \PHP for future internal tightly-bound components" If vote 1 were passed, the next vote would be on this RFC, and would cover policy on namespace usage and would be something like: "The \PHP namespace must remain empty, except for child namespaces". This would be to prevent the problem of colliding internals symbols throughout the rest of PHP's maintained lifespan (such as what if there was something else added to core called Token). Vote 3 would mandate only autoloadable classes / interfaces / traits etc etc were used, allowing userland polyfills (where sensible) to provide a route for users to begin using newer API functionality without an immediate upgrade. Votes 1 and 2 passing would put us on a pretty good course for long-term sanity. Vote 1 passing and 2 failing would result in part of the problem just being moved to \PHP and exposing us to symbol collision further down the line. If vote 1 failed, we would have to consider if this RFC would pass with its tigher constraints. The question is, how would we vote on extra uses for PHP. While the alternative RFC mandates its use for tightly coupled, I think it makes a lot of sense to add extra things to it, such as re-designed collections (borg Ds?) in \PHP\Collections in a similar fashion to: https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=netframework-4.8 Mark Randall

Mark Randall

6 years ago
On 15/04/2020 12:21, Mark Randall wrote:
> https://wiki.php.net/rfc/php_namespace_policy
As it has come up a few times, I wanted to provide examples of where programming languages mount their own standard libraries inside a main namespace: Java (java.*) https://en.wikipedia.org/wiki/Java_Platform,_Standard_Edition .NET (System.*) https://docs.microsoft.com/en-us/dotnet/api/system?view=dotnet-plat-ext-3.1 C++ (std::*) https://en.cppreference.com/w/cpp/header I would be interested in hearing arguments why such a strategy adopted with great success by many of the most popular and well-developed languages, is inappropriate for PHP. Mark Randall