Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <DA.B9.38526.1FBBF574@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 12 Dec 2007 10:45:23 +0000
Reply-To: nrixham@gmail.com
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
References: <475F1984.603@chiaraquartet.net> <1197450581.27917.2.camel@localhost.localdomain>
In-Reply-To: <1197450581.27917.2.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespace improvements to be committed very soon -final
 review
From: nrixham@gmail.com (Nathan Rixham)

Surely the noise coming from outside are people's valid opinions? I mean 
it's the people making the noise who have to live with decisions made on 
the internals list, on a daily basis, and for most there income depends 
on it.

It's not just php you're discussing, it's thousands of developers 
working environment.. think of changes like this as somebody coming in 
and cleaning your pc and files structure up for you, yeah they're trying 
to help, but you had your files where you wanted them already..

No Offense and agreed on the spam issue!

Nathan

Jani Taskinen wrote:
> Nice to hear some work is done but I get very annoyed every time I see
> the words "behind the scenes" (or something alike). I guess it was
> because it's impossible to discuss anything on internals without the
> noise coming from "outside"..? Could we finally make this list read-only
> for every one but the @php.net people? I get enough spam already, spam
> from this list is not something everyone should suffer from.
> 
> --Jani
> 
> 
> On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:
>> Hi,
>>
>> I've been furiously working behind the scenes with Stas and Dmitry, and
>> have some enhancements to namespaces in the form of 2 patches.
>>
>> 1) multiple namespaces per file
>> 2) use ::name;
>>
>> 1) multiple namespaces per file
>>
>> This is implemented as such:
>>
>> <?php
>> namespace one;
>> use Blah::A;
>> // code
>> namespace two;
>> use Foo::A;
>> ?>
>>
>> The example above shows that imported names are reset at each namespace
>> declaration.  There is no prohibition on this code:
>>
>> <?php
>> namespace one; {
>> use Blah::A;
>> // code
>> }
>> namespace two; {
>> use Foo::A;
>> // code
>> }
>> ?>
>>
>> Users who wish to use brackets may do so.  The performance penalty
>> imposed by using brackets is minor for some cases, and for users who are
>> following the recommended practice of 1 namespace per file, the syntax
>> is ideal.
>>
>> Patch is:
>>
>> http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
>> http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt
>>
>> Note that non-namespaced code cannot be present in a file containing
>> namespaces.  For users who are bundling, this will mean you will need to
>> create 2 files, one with non-namespaced code, and one with namespaced
>> code.  This minor prohibition is a design decision, not a technical
>> problem in the implementation.
>>
>> 2) use ::name
>>
>> This code:
>>
>> <?php
>> namespace Whatever;
>> use MDB2; // import PEAR's ::MDB2 from global scope
>> $a = MDB2::connect();
>> ?>
>>
>> is currently impossible, which will make namespacing old code harder. 
>> The patch introduces this new syntax to import names from the global
>> namespace:
>>
>> <?php
>> use ::MDB2, ::strlen as len;
>> ?>
>>
>> http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
>> http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt
>>
>> These patches are for review of both serious technical and serious
>> implementation issues.  In order to help move things along, I'd like to
>> define "serious" as something directly related to the implementation
>> that would cause a failure in PHP's ability to run scripts
>> deterministically, or some kind of memory leak/crash.
>>
>> commit is planned for the next 24 hours or so, but of course any issues
>> found in review can be fixed.  The patches are short, so in the worst
>> case, reverting is not difficult.
>>
>> Thanks,
>> Greg
>>