This RFC deals with the open questions in regards to namespaces that came up during the alpha release of PHP 5.3.
During alpha phase of PHP 5.0 there was a namespace implementation that was very close to the one of C++. Because an inconsistency between namespace separator '::' and ternary operator's ':' could not be solved, namespace were finally removed. Durning development of PHP 5.3 namespace came up again and a solution for the conflict was found. The implementation did undergo several steps and small changes and finally settled down with support for multiple namespaces per file using the keyword 'namespace' in a simple statement that would be closed by a ';' and changed all name lookup in the code that follows.
The following issues have been identified:
The keyword has been discussed several times and even though a real explanation has not been found the agreement is that we think of namespaces literally. Furthermore the names are in no way related to the file system structure as is with Java packages for instance. The immediate conclusion is that we stick to the keyword. This also has the advantage that many people have seen namespace as a reserved keyword even when it was not a reserved keyword. This part is thus not open for discussion.
We need to describe how we think of namespaces. Right now the PHP runtime treats namespaces as simple text replacements. That is the runtime will only resolve names in the current and global namespace. With this in mind it does not matter whether we do namespaces as blocks or labels. This difference comes from experience, comparison to existing implementations, expectation and consistency.
PHP needs to support compiler caches and their way of name resolution. This is at the moment bound to filenames and as a consequence we cannot allow any code that potentially requires name lookup. This means we could only allow statements outside namespaces that either never do name lookup or we need special forms of those that disallow name lookup outside namespaces. In fact this seems only relevant to define() and include/require.
Include as well as require do not carry over namespace information. This is a problematic as it allows for functions with mixed inner namespace resolution:
--foo.php
namespace foo;
function test{} {
echo __NAMESPACE__ . "\n";
include 'bar.php';
echo __NAMESPACE__ . "\n";
}
--bar.php
// namespace bar; echo __NAMESPACE__ . "\n";
The above shows 'foo', '', 'foo'. Further more the namespace statement in bar.php is legal and leads to 'foo', 'bar', foo'. It also means we kind of allow nested namespaces. The reason we need to allow include/require inside functions/methods is to support the common way of dynamic module loading.
We do not want to add special forms of require/include that do or not do carry over the current namespace and disallow namespace declarations if carried over.
This leaves us with define() as well as with require and include without carrying over the current namespace. For define we clearly allow name resolution:
$> php -r 'class C { const c = 42; } define(“F”, C::c);'
This in some way also applies to require and include because the both allow constants and variables. However define is a function and does not allow special treatment in the parser. Require and include on the other hand are parser states and take single expression as parameter. This expression can easily be turned into two different things. A full expression and a string only. The string only version can be allowed outside namespaces.
PHP uses simple text replacement for namespace resolution and thus can easily allow nested namespaces without any technical issue whatsoever.
We propose to add namespaces as block structures and drop 'namespace foo;' in favor of 'namespace foo: ; endnamespace;', as in this patch. The tests are provided in a second patch.
In a second step nesting namespaces should be supported. This can easily be done by simply removing the corresponding error messages.