Hi Greg,
How is this different from my original proposal
(http://news.php.net/php.internals/34097,
http://news.php.net/php.internals/36822)?
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
