[RFC] [Discussion] Namespaces in Core

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.

Hi 'Fleshgrinder',

I object to this RFC on principle.

RFC's are supposed to be opionated. They are supposed to present an
argument for why we should do something, and why doing that is a good
idea.

This RFC does not do that; it presents a series of questions to vote
on, without any clear presentation of what problem they are solving or
why people should be vote for the RFC.

Asking people to vote on things like this, leads to choice being made
at random, when there may not even be a need to make a choice in the
first place.

These parts of the RFC are particularly lacking justification:

Allow plural nouns in namespaces? Yes/No
Use namespace for the language itself (in the future)? Yes/No
Name of the language namespace? core/lang
Use namespace for tiny self-encapsulated things (in the future)? Yes/No
Name of that namespace? std/util

In addition, there are problems with other parts of the RFC.

Coding Standard? snake_case/PascalCase
Shouldn't this be part of the other RFC?

This could help to avoid those 1,000+ LOC files
Splitting files to only contain related things is a good idea.
Splitting related things into separate files, just because some
arbitrary line limit has been reached, is not.

From the RFC:

Introduce namespaces to user-level symbols to avoid collisions with user defined symbols

Use namespace for the language itself (in the future)? Yes/No

From email, Fleshgrinder wrote:

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.

If this is actually problem, a better solution might be just reserve
the global namespace in addition to the 'PHP' namespace. However the
RFC does not say why it is a problem that needs addressing, and so we
cannot explore possible solutions.

Multiple people have given you feedback that your idea of using a top
level 'PHP' vendor namespace isn't a good match for the project.
Rather than rephrasing what they have already said, I will just remind
you of an earlier reply:

From http://news.php.net/php.internals/98225

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.

cheers
Dan
Ack