Namespaces in Core

From: Date: Mon, 06 Feb 2017 17:21:05 +0000
Subject: Namespaces in Core
Groups: php.internals 
Request: Send a blank email to internals+get-98218@lists.php.net to get a copy of this message
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. -- Richard "Fleshgrinder" Fussenegger

« previous php.internals (#98218) next »