Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31810
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error)
In-Reply-To: <46CB3882.7090408@chiaraquartet.net>
References: <46C9F217.8040804@chiaraquartet.net> <200708210039.26755.larry@garfieldtech.com> <46CA7EBF.20909@zend.com> <46CB3882.7090408@chiaraquartet.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <2E8520C2-0B46-47CB-8B7F-2A25FF3DAA6A@bitxtender.com>
Cc: Stanislav Malyshev <stas@zend.com>,
 internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Tue, 21 Aug 2007 21:41:56 +0200
To: Gregory Beaver <greg@chiaraquartet.net>
Subject: Re: [PHP-DEV] [PATCH] allowing multiple namespaces per file plusnamespaces with brackets
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

I think there should be just one way to designate a namespace, not  
two different ones with different behaviors.

David



Am 21.08.2007 um 21:09 schrieb Gregory Beaver:

> Stanislav Malyshev wrote:
>>> What happens if you mix them?
>>> <?php namespace baz;
>>>
>>> namespace foo {
>>>   class Bar {
>>>     ...
>>>   }
>>> }
>>> ?>
>>
>> That's not the fun yet. This is:
>>
>> <?php
>> namespace baz;
>>
>> namespace foo { ...whatever... }
>>
>> class bar {}
>>
>> ?>
>
> If by fun you mean "Fatal error: Namespace cannot be declared twice
> (without brackets) or nested within brackets in ..."
>
> To clarify, the patch works as follows:
>
> when namespace baz; is encountered, CG(current_namespace) is set to a
> non-NULL zstr (name->u.constant).  Later on, when you try to namespace
> foo {}, this check fails:
>
> 	if (CG(current_namespace)) {
> 		zend_error(E_COMPILE_ERROR, "Namespace cannot be declared twice
> (without brackets) or nested within brackets");
> 	}
>
> In other words, if there is a current namespace present, you can't
> declare another or redeclare.  This code also fails with the same
> E_COMPILE_ERROR above (and is one of the new tests in the patch):
>
> <?php
> namespace baz;
> namespace foo;
>
> class bar {}
> ?>
>
>> Now, is bar in namespace baz or not? I guess it is, otherwise it  
>> stops
>> making any sense. So now when you see in the code it says "class bar"
>> what do you do to know which namespace it is? Right, you go up to the
>> code, counting closing and open brackets and hoping you didn't  
>> miss any
>> and try to figure out if it's that main namespace or one of the other
>> ones. Now next question - how ones in namespace foo are supposed  
>> to call
>> class bar? They'd have to call it by full name, baz::bar, right?  
>> Welcome
>> back, long names. But wait, we could use an import, right? So now  
>> we'd
>> have block-local imports. And we'd have to track them per
>> namespace-block. BTW, what about imports in baz - are they active in
>> foo? What if baz wants to talk to class in foo - should it import it?
>> And BTW - how the patch solves it - I didn't read all of it, but not
>> sure it does it correctly.
>>
>>> Would the compiler have a heart attack if someone did:
>>>
>>> <?php
>>> namespace foo {
>>>   namespace baz {
>>>     class Bar { ... }
>>>   }
>>> }
>>> ?>
>>
>> This syntax implies that baz has access to names in foo. The separate
>> syntax doesn't. But that's only part of the story - remember the
>> names/imports story above? Now take that and make it unlimited depth
>> stack, since you'd have to track everything on *each* nesting level
>> separately. I wouldn't want to open this can of worms. That'd produce
>> messy engine and messy code.
>
> I don't want to open this can of worms either, and so I didn't. :)
>
> Greg
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>