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