Re: simple solution to another namespace conundrum?

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 >