On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> Hey guys! :) > > First: I like namespaces in Core but here me out! > > https://wiki.php.net/rfc/libsodium > > The second vote is clearly going to be that this new feature is added to > the core with a namespace. I already complained about this but it seems > to go unnoticed or others do not see the potential problems that might > be introduced by this. > > Sodium (or insert possible future namespace in Core here) might be a > valid username and existing community standards use the first namespace > for the vendor. Using those first level vendor namespaces in Core always > comes a long with a potential problem for users with that name. > > The PHP (case does not matter) would be the proper vendor name to put > Core stuff in, as far as I remember it is also reserved for PHP > functionality. There were also numerous discussions about providing a > cleaned up API there while maintaining backwards compatibility via > aliases and so forth in the non-namespaced Core stuff. > > Using the PHP vendor name as first level namespace would defeat problems > with userland namespaces and be a much safer choice. Hence, > `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice. > > There is another issue regarding auto-loading. If we randomly introduce > first-level namespaces we de facto make it much harder for us to exclude > some pattern from the auto-loader. However, putting everything Core > related into `Php` would mean that we can always sidestep any > auto-loader calls since we know up front that this must be a C thing. > > Most package and/or namespace system do that to avoid problems with > their users: > > - Java: `java*` > - C#: `System*` > - C++: `::std*` > - Rust: `core::*` and `std::*` [1] > - Scala: `scala*` > - Kotlin: `kotlin*` > - Ceylon: `ceylon*` > - ... > > Obviously there are some counter examples too: > > - Go: random > - Python: random > - Javascript: random > - ... > > But at least they go through an extensive standardization process where > the names are being discussed ad infinitum to ensure that they are super > generic and thus useful. It is very unlikely that `IO` or `OS` collides > with a username. > > I personally would love to see namespaces but I definitely do not want > to see random namespaces. I hope we are not going down a road that is > hard to repair later, like with so many other things we have in Core today. > > [1] Rust decided against vendor names for some reasons they explained > once in a blog post. I believe that this will become a problem for them > at some point in time since coming up with nice names over time for > users is very hard. We'll see if Rust persists and invalidates my concerns. > 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
