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
Hi Mark,
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
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
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.
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.
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
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
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.
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
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
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