Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98239 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34767 invoked from network); 7 Feb 2017 11:00:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Feb 2017 11:00:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Received: from [82.113.146.227] ([82.113.146.227:49652] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/A7-03389-3E8A9985 for ; Tue, 07 Feb 2017 06:00:52 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 8E9B010CEB1; Tue, 7 Feb 2017 11:00:48 +0000 (GMT) Date: Tue, 7 Feb 2017 11:00:48 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: Nikita Popov cc: PHP internals In-Reply-To: Message-ID: References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [PHP-DEV] Namespaces in Core From: derick@php.net (Derick Rethans) On Mon, 6 Feb 2017, Nikita Popov wrote: > On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder wrote: > > > First: I like namespaces in Core but here me out! > 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. > > Extensions which are not of this type should not live in the PHP namespace, > because they don't have anything specifically to do with php, apart from > the circumstance that they happen to be bundled at the current point in > time. Remember that extension may move from being bundled to being in PECL > and vice versa. If we decide to bundle the MongoDB extension with php, > would we rename the currently used MongoDB namespace to PHP\MongoDB? If we > decided to move it back to PECL, would the namespace go back to just > MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP > anymore? Should all new extensions be written with a PHP namespace to > account for the possibility of the extension being bundled with PHP at a > later point in time (even if there are no concrete plans to do so)? > > I would answer No to these questions. The namespace MongoDB is not, as you > say, "random", it is *meaningful*. The namespace PHP is (with the > exceptions in the first paragraph notwithstanding) meaningless and an > artifact of the distribution mechanism, a mechanism which may change over > time. I very much agree with all of this, and would like to add, that for a *long* time it has been documented that PHP owns the top-level namespace: http://php.net/manual/en/userlandnaming.rules.php In any case, a discussion to namespace any existing PHP functionality should really wait until PHP 8 - and that means, that if we decide to put Sodium in PHP 7.x, it should not be namespaced out of consistenct *no matter what the RFC result* says. cheers, Derick