[PATCH] allowing multiple namespaces per file plus namespaces with brackets

Rasmus Lerdorf wrote:

Hi Rasmus, I'm actually certain that the patch doesn't change any of the symbol resolution logic or add any need to move things from the compile-time to the executor. This is because the namespace implementation basically works more like a #define macro to auto-prepend class names and function names with namespace names. Old logic: request start => CG(namespace) = NULL T_NAMESPACE ...; zend_do_namespace() => defines CG(namespace) which is used for creating class and function entries php junk compile end => if (CG(namespace)) destruct CG(namespace), CG(namespace) = NULL New logic: request start => CG(namespace) = NULL [potential php junk] T_NAMESPACE ... { zend_do_namespace() => defines CG(namespace) which is used for creating class and function entries php junk } zend_do_end_namespace() => destruct CG(namespace), CG(namespace) = NULL php junk (which can include class/function entries, although that's a terrible idea) T_NAMESPACE ... { zend_do_namespace() => defines CG(namespace) which is used for creating class and function entries php junk } zend_do_end_namespace() => destruct CG(namespace), CG(namespace) = NULL compile end => if (CG(namespace)) destruct CG(namespace), CG(namespace) = NULL In other words, the only difference is that mid-parse the namespace #define-like prefix can be modified or removed. Greg

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:

Ah, I didn't read it good enough - was under impression mixing them was allowed.

Hello Dmitry, so please stick to your own arguments and don't chnage them at random. And spare us with stupid arguemnts. The renaming patch was perfectly valid when offered and I am sure the author of that patch would fix it before comitting if allowed to. So saying that the patch is wrong just because normal development continued is very offending behavior and does not bring us anywhere. And sorry but in cases like this I will stick to pointing them out. Whether anyone likes it or not. marcus Tuesday, August 21, 2007, 3:28:11 PM, you wrote:

Best regards, Marcus

Hi, I'll try to answer some of the questions I saw here based on Gregory's patch and I will ask for more information about external things that I probably misunderstood. > And nested namespaces really make a mess of this if something like this > is allowed: > > foo.inc: > namespace A { > include 'bar.inc'; > } > > > bar.inc: > namespace B { > ... > } This is not currently allowed. There are still a limitation of nested namespaces. > <?php > namespace baz; > > namespace foo { > class Bar { > ... > } > } > ?> It's the same as the previous situation. You have a current namespace scope, so it'll raise an error. > Would the compiler have a heart attack if someone did: > > <?php > namespace foo { > namespace baz { > class Bar { ... } > } > } > ?> It'll only throw this error: "Namespace cannot be defined twice (without brackets) or nested within brackets" > <?php > namespace baz; > > namespace foo { ...whatever... } > > class bar {} > > ?> > > Now, is bar in namespace baz or not? No, there is a syntax error. And you'll receive the same message I showed before. > Also this change is inconsistent with renaming "namespace" to "package". Exactly. I am interested to see namespace support in PHP too, but the current implementation tell me the contrary. Gregory purposed a patch to remove one of the PHP namespace limitation. =) AFAIK, this patch do not have performance impact. It only tries to add another way to define namespaces. So it's like the original implementation, but it holds the current_namespace based in the current scope (old behavior was the entire file, not it's either the entire file OR the namespace block (both are disallowed)). I don't understand very well what Rasmus tried to mention with nested namespaces and opcache, but seems there're a limitation and I am interested to know which (if possible, try to explain in other words)... =) Why am I asking this? I am changing the Gregory's patch... now, current_namespace holds a zval. I am changing it first to a stack, and pushing and popping the namespaces based on block declaration. So, the piece of code Stanislav pointed before: namespace Foo; namespace Bar { class Test {} } class Test {} Is being resolved as Foo::Bar::Test and Foo::Test. BUT... it's not working as expected yet. Currently it's defining as: Foo::Test and Bar::Test. This is my first try to do something internally in PHP, so I'm having huge headaches to modify the source. My first try to avoid this: namespace Long::Nspace::Declaration::In:The::TopOf::TheFile; class Foo {} To something more clean and organized, like: namespace Logn { namespace Nspace { ... } } I know there're a lot of other impacts by doing this, but since this is a draft yet, it can be implemented more and more functionalities, like Inner Namespace able to use parent definitions. But this is just a beginning. Also, mentioning the Rasmus piece of code: foo.inc: namespace A { include 'bar.inc'; } bar.inc: namespace B { ... } I don't know how do you control it internally, but as long as this is the only call in the entire script, the right scope should be: A::B, and not B. If I include bar.inc outside any namespace scope, then it should be B. Waiting a response... Best regards, On 8/21/07, Stanislav Malyshev <stas@zend.com> wrote: > > Hello Dmitry, > > > > LOL!!!!! > > > > climbing up the chair again, this is the most stupiest argument ever. > > Could you please keep the attitude down? Calling names is not going to > help anything. > > > didn't you just yesterday suggest we keep it namespace anyway until we > > are done. And didn't you guys say that we might end up with something that > > really is namespaces anyway. > > > > Please guyse read your own arguments if you do not manage to remember them. > > We discuss and consider a lot of options. Including ones that > contradict. That's the meaning of discussion - to consider all options > and find out the best. Dmitry was absolutely right to note that naming > can wait until we finalize all the concept, and that braces support > namespace naming. Though, they create many other problems, which we need > to have addressed before we could consider adding it to the concept. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com São Carlos - SP/Brazil

Stanislav Malyshev wrote:

s/files/functions/ I mis-typed and didn't notice, sorry.

Careful Stas :), you probably missed the "import foo::bar;" This code works just fine: <?php namespace foo { class bar {} } namespace gronk { class bar {} } ?> No fatal errors, everybody is happy. The problem is importing the "bar" identifier. This code also fails with the same fatal error for the same reason: file1.php: <?php namespace foo; class bar {} ?> file2.php: <?php namespace gronk; import foo::bar; class bar {} ?>

It still doesn't. As I pointed out above, the same error is possible with the current implementation pre-my patch.

I don't care about C++. I'm only talking about the patch I proposed. Thanks, Greg