Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98236
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <C8.A6.03389.36F99985@pb1.pair.com>
To: internals@lists.php.net
References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com> <CAF+90c9MWGkR3d9-vn-o_y_brs0XhOXapGD5cxq5r+v60pGVAg@mail.gmail.com> <04295b76-3e0d-5ea3-7b4e-d07a15db4243@fleshgrinder.com>
In-Reply-To: <04295b76-3e0d-5ea3-7b4e-d07a15db4243@fleshgrinder.com>
Date: Tue, 7 Feb 2017 10:20:14 -0000
Lines: 6
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
Importance: Normal
Subject: Re: [PHP-DEV] Namespaces in Core
From: TonyMarston@hotmail.com ("Tony Marston")

"Fleshgrinder"  wrote in message 
news:04295b76-3e0d-5ea3-7b4e-d07a15db4243@fleshgrinder.com...
>
>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

Not to me, it isn't! I have been using PHP since 2002 and I have never had 
an issue with this. Perhaps this is because I don't have weird development 
practices.

> 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!
>

Introducing a new rule which breaks code that has been running happily for 
the past 15 years sounds like a bad idea to me. VERY bad.

-- 
Tony Marston