Re: [PATCH] bracketed namespace, unset import, removal of namespace blah;

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.