On 6 February 2017 at 17:21, 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. > I don't often chime in on the internals list, so please excuse this interruption. Slinking in a vote which essentially is about adopting namespaces in core, via new library RFC, is not the way to go about changing our coding standards. In short, I don't want to the see the situation where this extension gets merged in to 7.2 (which it should be :)) only to have someone ask, "what about the 'php' top-level namespace?" and we all shrug and mutter, "too late" under our breaths. > > 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. > > -- > Richard "Fleshgrinder" Fussenegger > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
