Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98227
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.179 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c9MWGkR3d9-vn-o_y_brs0XhOXapGD5cxq5r+v60pGVAg@mail.gmail.com>
References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com> <CAF+90c9MWGkR3d9-vn-o_y_brs0XhOXapGD5cxq5r+v60pGVAg@mail.gmail.com>
Date: Mon, 6 Feb 2017 16:38:34 -0500
Message-ID: <CAESVnVry0ns982aYTXa+wsSysv6zHe_Vkfkt63iUV9UsXNFpCg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: 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 3:47 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it provides
> an AST for PHP specifically. Similarly the tokenizer extension could
> reasonably be namespaced as php\tokenizer.
>
Okay, I'm pickin' up what yer layin' down.  Perhaps the question then
should be asked in the other direction:

Given PHP's long history and fanatical dedication to BC, should all
bundled/core classes/functions/constants ALWAYS remain in the root
namespace with a strong advisory to userspace libraries and
applications to use vendor namespacing (which by and large, is
precisely the status quo).

If that makes sense, then that's another reason not to bring Sodium in
as a namespaced library of functions.

-Sara