Gregory Beaver wrote:
Hi again,
The attached patch:
1) adds unset import syntax for declaring a namespace to have local
import scope (it does NOT affect variable scope or the global
class/function table)
2) removes namespace Name; syntax (this I am happy to add this back in
if there is uproar)
3) fixes all misspellings of coflict in zend_compile.c (2 total)
4) uses a more intuitive error message Namespace 'Foo' cannot be nested
(already within 'Bar' namespace) for nested namespaces
5) updates tests to use brackets
it can also be found at
http://pear.php.net/~greg/namespace_brackets_unsetimport.patch.txt
After Stanislav's criticisms of my smart import namespace patch and
David's criticism of confusing dual syntax, I decided to take another
approach to the import issue. Although I would rather only support one
use case of namespace blah {}, I do think that realistically PHP should
be as intuitive as possible. Having a separate scope by default for
import that does not inherit from the global scope is not very intuitive.
So, instead of resetting current_import by default, this patch makes
import global by default and local by explicit syntax via:
namespace MyNamespace unset import {
}
For example:
?php
import foo::bar;
namespace foo {
class bar {
function __construct()
{
echo __NAMESPACE__ . ::bar\n;
}
}
// foo::bar
new bar;
}
namespace gronk unset import {
import foo::bar as foobar;
// uses local import
class bar extends foobar {
function __construct()
{
echo __NAMESPACE__ . ::bar\n;
}
}
// gronk::bar
new bar;
// foo::bar
new foobar;
}
namespace last {
// uses global import
// foo::bar
new bar;
}
// uses global import
// foo::bar
new bar;
?
This code demonstrates that in the (useless) namespace last {}
declaration, we can access the global import. This way, since import
conflicts are not the norm but the exception, they can be handled on a
case-by-case basis. Let's remember that in most cases users will not be
declaring multiple namespaces, but instead doing this use case for the
import keyword:
?php
require 'library1/foo.php';
require 'framework2/foo.php';
import framework2::foo as foo;
import library1::foo as bar;
...
?
Again, the primary use case for multiple namespaces in the same file
that I hope to support is combining multiple pre-existing files into a
single file. As each file is expected to be self-contained, this means
that by having import statements within the namespace {} declaration and
using unset import the files are guaranteed to combine with any other
separate file that follows these rules. Even if authors do not use
unset import, it can easily be added by hand or automatically when
glomming the separate files into a single file.
Files with global imports will be out of luck if there are naming
conflicts with the global namespace (similar to today's pre-namespace
conundrum), but as class files or functions are almost always libraries
of some kind, this is unlikely if the documentation is clear on best
practices.
Greg
I'm not sure if this is the best way to take it, to be honest I had to
re-read your post 2x to figure out what was actually going on and why.
The unset import part is odd and not very transparent to the average
user (imo). Sure, with good documentation you could solve that, but imo
we should look for easier to understand syntax instead. I like the idea,
but it adds a lot of complexity with (as far as I can tell) little gain
vs. the original 1-file-1-namespace patch.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
