Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98225 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83974 invoked from network); 6 Feb 2017 21:01:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2017 21:01:58 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.86 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.86 mx105.easyname.com Received: from [77.244.243.86] ([77.244.243.86:47466] helo=mx105.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B2/32-03389-444E8985 for ; Mon, 06 Feb 2017 16:01:56 -0500 Received: from cable-81-173-135-7.netcologne.de ([81.173.135.7] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1caqQ3-0005fV-Kr; Mon, 06 Feb 2017 21:01:53 +0000 Reply-To: internals@lists.php.net References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com> To: Nikita Popov , PHP internals Message-ID: <04295b76-3e0d-5ea3-7b4e-d07a15db4243@fleshgrinder.com> Date: Mon, 6 Feb 2017 22:01:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-DNSBL-PBLSPAMHAUS: YES Subject: Re: [PHP-DEV] Namespaces in Core From: php@fleshgrinder.com (Fleshgrinder) On 2/6/2017 9:47 PM, Nikita Popov 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. > > 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. > > Regards, Nikita > I thought about this too. I hope you understood that the main reasoning for me to choose a well known namespace prefix is related to auto-loading and when to trigger it. The lack of function and constant auto-loading is a pain and having well known prefixes could solve the issue since we would never require to even look at the auto-loader if the namespace starts with php. Obviously this could be solved for C extensions by allowing them to register another prefix that should not be auto-loaded: Sodium, MongoDB, ... Another solution could be to use pecl as their prefix. Although this couples it to the packaging system which might not be so nice. Any name that is tied to a company name or something else that makes things impossible for users to claim (Oracle, MongoDB, ...) is not a problem. In case of sodium that would probably be Paragon but Sodium might be fine too. I am not the judge here, the only thing I want is to ensure that this does not go unseen and that the potential of breaking something is real if we choose a random route like some others do. Not saying that we cannot do it, big ecosystems live without problems doing the same. However, it should be a very conscious choice and none that is taken lightly: meaning rules! -- Richard "Fleshgrinder" Fussenegger