Re: [PATCH] allowing multiple namespaces per file plusnamespaces with brackets
| From: | David Zülke | Date: | Tue, 21 Aug 2007 19:41:56 +0000 |
| Subject: | Re: [PATCH] allowing multiple namespaces per file plusnamespaces with brackets | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-31810@lists.php.net to get a copy of this message | ||
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: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 {} ?>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 {} ?>...} } ?>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.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.phpWould the compiler have a heart attack if someone did: <?php namespace foo { namespace baz {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.class Bar { ... }} } ?>