Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31828
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 213.75.38.118 as permitted sender)
Message-ID: <46CBFDD5.8020908@php.net>
Date: Wed, 22 Aug 2007 11:11:49 +0200
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Gregory Beaver <greg@chiaraquartet.net>
CC: internals Mailing List <internals@lists.php.net>
References: <46CBA2B6.2010600@chiaraquartet.net>
In-Reply-To: <46CBA2B6.2010600@chiaraquartet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] bracketed namespace, unset import, removal of namespace
 blah;
From: tularis@php.net ("M. Sokolewicz")

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.