Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38476
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <485BD681.5080309@zend.com>
Date: Fri, 20 Jun 2008 20:10:41 +0400
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Gregory Beaver <greg@chiaraquartet.net>
CC: Andi Gutmans <andi@zend.com>, Stanislav Malyshev <stas@zend.com>, 
 internals Mailing List <internals@lists.php.net>
References: <485BD1C0.8040302@chiaraquartet.net>
In-Reply-To: <485BD1C0.8040302@chiaraquartet.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: simple solution to another namespace conundrum?
From: dmitry@zend.com (Dmitry Stogov)

Looks fine, but probably we should emit error only if class declared in
the same source file.

Thanks. Dmitry.

Gregory Beaver wrote:
> Hi,
> 
> You probably have seen Derick's blog post
> http://www.derickrethans.nl/namespaces_in_php.php
> 
> It occurred to me today that there might be a simple, elegant solution
> to this problem.
> 
> First, let's imagine someone writes this code:
> 
> <?php
> include '/path/to/library/Closure.php';
> use Fancy::Closure;
> 
> $a = new Closure('for ($a = 1;$a<10;$a++) docrap();');
> ?>
> 
> Now, in PHP 5.4, we introduce an internal class "Closure" and the user's
> code suddenly breaks on the "use" statement because we check for an
> internal name conflict.
> 
> Here's the kicker: why do we need to worry about a name conflict?  This
> user's code was designed to work exclusively with Fancy::Closure, and
> doesn't care about any present or future internal classes that
> conflict!  Also, because this is a compile-time alias that only affects
> the current script file, if we were to allow the above user's code to
> essentially override the internal Closure class, there is no possible
> harm because
> 
> 1) the user explicitly imported Fancy::Closure
> 2) the user therefore never intends to use the internal ::Closure in
> this script
> 
> In fact, the same thing is true for existing classnames.  Why should we
> care if a user does this?
> 
> <?php
> include '/path/to/my/date/lib.php';
> use My::DateTime;
> 
> $a = new DateTime('2006/04/05');
> ?>
> 
> The user is obviously intentionally creating a "DateTime" class, and
> doesn't care about the internal classname in this script.
> 
> The attached patch against PHP_5_3 would fix the issue by eliminating
> the check for conflict with CG(class_table) in the global namespace for
> internal classes.  It however preserves this check for userspace classes
> so that (for instance) php-src/tests/Zend/ns_030.phpt does not fail. 
> The basic idea is that we do have control over the userspace classes we
> include, but have no control over the internal classes.
> 
> A new test would also be needed:
> 
> 066.php.inc:
> <?php
> namespace A;
> class B
> {
>     function __construct(){echo __CLASS__;}
> }
> ?>
> 
> --TEST--
> 066: Name ambiguity (import name & internal class name)
> --FILE--
> <?php
> include __DIR__ . '/066.php.inc';
> use A::B as stdClass;
> 
> new stdClass();
> --EXPECT--
> A::B
> 
> Thanks,
> Greg
>