Re: simple solution to another namespace conundrum?

Hi Greg, How is this different from my original proposal (http://news.php.net/php.internals/34097, http://news.php.net/php.internals/34097)? -- Jessie Hernandez Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282) 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