Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98221
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.181 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com>
References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com>
Date: Mon, 6 Feb 2017 15:27:17 -0500
Message-ID: <CAESVnVrLtPd6WA9idTe=srrx-xtx0YMgwgD1L5fXkBrUDchjZQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Namespaces in Core
From: pollita@php.net (Sara Golemon)

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder <php@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.