On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> First: I like namespaces in Core but here me out!
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
I've been having this same thought lately since looking at the sodium
RFC. Here are my thoughts, centered on the goal of having classes
(and maybe functions?) in a \php\{extname}\ namespace hierarchy.
New classes within 7.2 (e.g. \HashContext) to be moved without concern
for BC (e.g. \php\Hash\HashContext)
Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)
"Aliasing" could be potentially accomplished in a few ways:
1. Literally just class_alias(). Put another copy of the
zend_class_entry into the EG(class_table) under a different name.
2. "Auto-use": Compile-time analysis of classname: "Is it in this list
of BC classes? Implicitly map it."
3. ...?
I like #2 because we can raise compile-time deprecation warnings and
we don't introduce any runtime overhead for most cases.
Obviously, no removal of support for non-namespaced names until AT LEAST PHP 8.0
This two big unanswered questions for me before I'd put this into an RFC are:
1. How to achieve BC in the best way
2. What to do about functions/constants? Instinct says move 'em just
like classes.
-Sara
P.S. - wrt libsodium, I think THIS issue is enough for me to come down
on the side of voting non-namespaced to avoid it being an odd-duck.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
