Namespaces in Core

> >Hi! > >> New classes within 7.2 (e.g. \HashContext) to be moved without concern >> for BC (e.g. \php\Hash\HashContext) >> >> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND >> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator) > >Do we really need this? I mean, it's not very likely that there's >another RecursiveIteratorIterator in PHP code, and in user code it'd be >namespaced anyway... It just looks like a lot of moving things around >without any visible (at least visible to me) benefit. And given that no >code would be able to use the long name for like 10 years, and even then >why would anybody use long name if short one works.... In general, I >don't see a point. New exts/features - sure.

> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >

> >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! >

> > 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!

> On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov <nikita.ppv@gmail.com> 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. > > > Okay, I'm pickin' up what yer layin' down. Perhaps the question then > should be asked in the other direction: > > Given PHP's long history and fanatical dedication to BC, should all > bundled/core classes/functions/constants ALWAYS remain in the root > namespace with a strong advisory to userspace libraries and > applications to use vendor namespacing (which by and large, is > precisely the status quo).

> If that makes sense, then that's another reason not to bring Sodium in > as a namespaced library of functions.

> > 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. > > Agree. If we ever need namespace for mongodb extension, it should be > mongodb (choose capitalization to your liking), not php\mongodb - php\ > should be things that are really php core or specifically deal with > aspects of php as a language - tokenizer, syntax, etc.

> On Mon, 6 Feb 2017, Nikita Popov wrote: > > > On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder <php@fleshgrinder.com> > wrote: > > > > > First: I like namespaces in Core but here me out! > > <snip> > > > 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. > > I very much agree with all of this, and would like to add, that for a > *long* time it has been documented that PHP owns the top-level > namespace: > http://php.net/manual/en/userlandnaming.rules.php > > In any case, a discussion to namespace any existing PHP functionality > should really wait until PHP 8 - and that means, that if we decide to > put Sodium in PHP 7.x, it should not be namespaced out of consistenct > *no matter what the RFC result* says. > >

>> I think the Sodium RFC vote is not about namespace but rather about >> breaking everything which already use the pecl extension. > Well, it's about both, that's why it's a hard question: in order not to break existing use of the extension, we need to break existing conventions by adding a namespace to core. > > I agree with Richard that this should be decided as a general policy, rather than a special exemption for this one extension, and then a fresh debate next time, and next...

> On 7 February 2017 at 17:56, Scott Arciszewski <scott@paragonie.com> wrote: >> I'm taking all the No votes spawned by this thread to mean "we >> don't want namespaced functions ever". > > That would be a bad assumption. >

> aka it should be a separate discussion to whether libsodium should be > included in PHP7.2. >