On Sat, Jun 10, 2017 at 1:13 PM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 6/10/2017 8:54 PM, Levi Morrison wrote: >> I gave this feedback before but I'll repeat it. I support namespaces >> in the core, with the `PHP` namespace (with whatever capitalization we >> decide) to be reserved *solely* for things related to the language >> itself such as lexer, parser, etc. >> >> I am fine with other extensions using namespaces but should use >> appropriately named ones. Using the `PHP` namespace to indicate >> something is packaged in core is a poor decision. We have moved >> existing extensions into core and it would not make sense to rename it >> simply because it was moved into core because it's a backwards >> compatibility break. Similarly we've moved at least one extension out >> of core and it doesn't make sense for it to have the `PHP` name when >> it's not in core, but renaming it is yet other backwards compatibility >> break. It's simply not prudent. Instead extensions should be named >> after what they are, the vendor they are for, or some other name; this >> is the same process user-land packages go through and core should not >> be different. >> > > Thanks for that, much appreciated. > > This is exactly what I am proposing. Only things that are provided > directly from the PHP Group should go into the PHP namespace. Any- and > everything else should go into appropriate vendor namespaces. > > I think that you are considering e.g. array functions as not being part > of PHP, and that you want to put them in a separate namespace. So > effectively we would have something like: > > PHP\Lexer > Arrays\Array > IO\File > Logging\Logger > Reflection\Reflector > Strings\String > UUIDs\UUID > > I personally do not like this approach. PHP is the vendor of these > things, thus, it should reside in the namespace of the vendor. Same > rules for everyone. IO for instance is not a vendor, it is a particular > use-case (working with files) and thus should not go directly into the > global namespace. > > There is imho no reason to move `PHP\Reflection\Reflector` to > `Reflection\Reflector` just because we decided, for whatever reason, to > remove reflection from core and instead providing it via PECL. PHP would > still be the vendor of it. > > The misconception that I am seeing is, that the PHP namespace is bound > to PHP, which it isn't: it is the vendor namespace of the PHP Group. > > The PHP community at large has settled with this approach, and I believe > that it is a very good approach. It effectively avoids namespace > collisions and helps to identify the vendor of a particular implementation. > > Would love to hear what others think about this. > > -- > Richard "Fleshgrinder" Fussenegger >
If we were starting from scratch maybe we'd do as you are proposing. However, there is absolutely zero value in these specific things being namespaced *anywhere*: - Arrays - Reflection - Strings - IO We already have established conventions and prefixes around these. Moving them to a namespace has zero value. I'm not sure what logging you are talking about for PHP. That leaves UUID, which I am fine with having its own namespace if there are enough functions, constants, classes, etc to support it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
