Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33914
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sambarrow.com from 205.234.132.11 cause and error)
To: Martin Alterisio <malterisio777@gmail.com>
Cc: Stanislav Malyshev <stas@zend.com>, PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <52dbac0f0712101159r3a27843bya005c5b43b1ef97e@mail.gmail.com>
References: <52dbac0f0712100837m76aeb9b1o8f2ff666451a73a9@mail.gmail.com>
	 <475D78D4.6050509@zend.com>
	 <52dbac0f0712101053k31b06733u6bbc9d3d38806a8a@mail.gmail.com>
	 <52dbac0f0712101159r3a27843bya005c5b43b1ef97e@mail.gmail.com>
Content-Type: text/plain
Date: Mon, 10 Dec 2007 15:45:09 -0500
Message-ID: <1197319509.3922.2.camel@sbarrow-desktop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Arguments (and suggestions) against the current
	implementation of namespaces
From: sam@sambarrow.com (Sam Barrow)

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 <malterisio777@gmail.com>:
> >
> >
> > > 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.