Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40599
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <48D7A5C8.7070503@zend.com>
Date: Mon, 22 Sep 2008 18:03:52 +0400
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Jochem Maas <jochem@iamjochem.com>
CC: Greg Beaver <greg@chiaraquartet.net>, 
 Lupus Michaelis <mickael+php@lupusmic.org>,
 internals@lists.php.net
References: <48D47532.8080102@chiaraquartet.net> <e666c3890809200924t28f1c585kad77729dd608c5ad@mail.gmail.com> <10845a340809201643q59e27211i471e09241f7253b1@mail.gmail.com> <200809202000.38870.larry@garfieldtech.com> <E5.0A.65213.536E5D84@pb1.pair.com> <48D66160.40306@chiaraquartet.net> <48D79672.4060208@zend.com> <48D79B9D.2080703@iamjochem.com>
In-Reply-To: <48D79B9D.2080703@iamjochem.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod
 class constant/ns constant
From: dmitry@zend.com (Dmitry Stogov)

Hi Jochem,

Jochem Maas wrote:
> Dmitry Stogov schreef:
>> Hi Greg,
>>
>> Greg Beaver wrote:
> 
> ...
> 
>>
>> I really don't see a reason to change namespace syntax into a less
>> intuitive way. 
> 
> I don't think the current implementation is intuitive, the ambiguity
> issues,
> (and possibly the name resolution order, although I can't grok what the
> current
> state of that is) are rather large WTFs.
> 
>> Your speed degradation argument isn't truth. The
>> ambiguity problem exists, but it is just an ability to use php in a
>> wrong way. Just don't create conflicting names.
> 
> which begs the question, what was namespaces created for?
> (that's a serious question because your statement has me truly confused)
> 
> we can "Just not create conflicting names" without namespaces and
> Stas has mentioned numerous times that namespace were not designed
> just to avoid having to repeatedly type long symbol names.
> 
> another thing, the ability to use php the wrong way is an argument
> that has been used lately both to:
> 
> 1. advocate leaving functionality as it is and putting the
> burden of responsibility on the developer to do the right thing.
> 
> 2. advocate changing functionality (or making the functionality illegal)
> in order to protect the user from doing something stupid.
> 
> .. not exactly consistent.
> 
> BTW, not creating conflicting names doesn't make the problem
> completely dissappear, code is still vulnerable breakage due to
> addition of new functions or classes in future version of the
> engine.

Right. Any touch of code can break something :)

Personally, I don't like inconsistencies and I would remove them if
possible. It wouldn't be a problem if PHP language was designed to
support namespaces, but it wasn't. Now we have to support backward
compatibility and provide new features without speed degradation and to
do it sometimes we have to make compromises because absolutely
consistent decisions are not possible in real life.

> 
>> I would recommend option #1 (stay it as is + document)
> 
> It would seem that it's yours' and Stas' responsibility to
> properly document how namespaces should be used because everyone
> else either doesn't care much about it or has, according to you,
> completely the wrong end of the stick with regard to the how/why/what
> of namespaces.
> 
> Can we at least count on you [both] to provide that documentation?

README.namespaces was committed into PHP_5_3 about year ago.

Thanks. Dmitry.