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
signature.asc
Description: OpenPGP digital signature
