Agreed. I don't see any point in this limitation. As for confusion,
debugging would not be too hard (just echo __NAMESPACE__), or brackets
would solve that problem.
On Mon, 2007-12-10 at 16:59 -0300, Martin Alterisio wrote:
> 2007/12/10, Martin Alterisio <[EMAIL PROTECTED]>:
> >
> >
> > > c) If bracketed namespaces are a no-go, consider the possibility of
> > > > declaring the full name of the namespaced element in its definition:
> > >
> > > Which would lead to people routinely mixing different namespaces inside
> > > one file. Bad idea. Also would kill namespaced functions and constants,
> > > which would make organizing libraries using those impossible.
> >
> >
> > Why would it lead to people routinely mixing different namespaces inside
> > one file?
> > Why is this bad in the first place?
> > Why is it the language the one to decide which is the better way to
> > organize code?
> >
> > Also, that would not kill neither namespaced functions nor constants:
> >
> > <?php
> > function namespaced::foo() {
> > ...
> > }
> > const namespaced::CONST = "I'm namespaced!";
> > ?>
>
>
> PS: An example of an organization model that wouldn't be possible with the
> current implementation of namespaces:
>
> Imagine that I'm writing a small module for my app. Just a main class, some
> helper classes and exceptions. For the purposes of this module I just find
> more organized to keep everything in a one file. Also, I expect exceptions
> only to be raised in most exceptional cases, therefore I see that is best to
> keep them in a subordinated but different namespace. I have two namespaces,
> e.g.: MyModule and MyModule:Exceptions, but I can't keep them in the same
> file. I don't see the point on having the exceptions in a different file,
> and I really prefer to keep the main namespace of my module as clean as
> possible. The language just took away the possibility to decide which
> organization schema I prefer.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
