Re: Namespaces in Core

"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