"Fleshgrinder" wrote in message
news:04295b76-3e0d-5ea3-7b4e-d07a15db4...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
