Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41153
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: <48F77938.1020206@zend.com>
Date: Thu, 16 Oct 2008 10:26:16 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Greg Beaver <greg@chiaraquartet.net>
CC: Lester Caine <lester@lsces.co.uk>, 
 PHP internals <internals@lists.php.net>
References: <48F6B3C5.9030102@chiaraquartet.net> <7f3ed2c30810152312h5391b25dke2695362c8d28d3b@mail.gmail.com> <48F6E50E.4010107@lsces.co.uk> <48F75BA3.30603@zend.com> <48F77416.3010106@chiaraquartet.net>
In-Reply-To: <48F77416.3010106@chiaraquartet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas'sproposal
 doesn't work
From: stas@zend.com (Stanislav Malyshev)

Hi!

> My point is that for this code:
> 
> <?php
> Classname::Method();
> ?>
> 
> The proposal does not solve the name conflict.  If no one rewrites their

Right, it does not. So doesn't yours - you need to modify the code in 
both cases.

> code to use Classname->Method(), then no one will be protected from the
> ambiguity.  I am thinking of the case where a user adds a new feature to

If nobody changes existing code then there's no ambiguity by definition. 
  If the code is changed, then of course one needs to change it in the 
right way, there's no way around that - you always can think of some 
wrong code that works, well, wrong.

> their existing code that uses a 3rd-party library with namespaced
> functions that accidentally conflict with the user's classes without

If you use 3rd party library that has same namespace as yours somebody 
had screwed up here - either you used namespace that doesn't belong to 
you or they used namespace that doesn't belong to them. In both cases 
the fix is un-screw-up the naming.

> their knowledge.  As third-party libraries become easier to distribute
> (which both phar and pyrus plan to do), this will become more of an issue.

Nobody should put their classes in PEAR namespace unless they are part 
of PEAR library, thus this scenario - when somebody outside of PEAR has 
conflict with PEAR functions/classes - is imaginary.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com