Re: Namespaces in Core
| From: | Fleshgrinder | Date: | Mon, 06 Feb 2017 21:01:45 +0000 |
| Subject: | Re: Namespaces in Core | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-98225@lists.php.net to get a copy of this message | ||
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