I thought global names were considered in the patch, but now that I
re-read Dmitry's post, only symbols in the namespace and internal
symbols are considered.
I read through most of the posts regarding namespaces, but could not
find a reason why global names are not looked up. Classes/functions
should first be looked up in the current namespace, if not found, then
they should be looked up in the global namespace, and if it is not found
there either, then there should be a check to see if there is an
internal class/function with the same name.
Dmitry, what's the reason this lookup logic wasn't used in your patch?
Regards,
Jessie
Gregory Beaver wrote:
Jessie Hernandez wrote:
Hi Greg,
How about this: any non-namespaced file that uses "use" statements is
implicitly put into the __php__ namespace (or whatever other name is
chosen, or having the namespace name be the path of the file)? With
this, "use" will never import any symbols into the global namespace.
Hi Jessie,
Imagine how that would affect this code:
file1.php:
<?php
function doSomething() {}
?>
PEAR2/DB.php: <hypothetical>
<?php
namespace PEAR2;
class DB {}
?>
file2.php:
<?php
include 'file1.php';
include 'PEAR2/DB.php';
use PEAR2::DB;
$a = new DB;
$b = doSomething();
?>
In file2.php, because there is a "use" statement, the rest of the file
is assumed to be in the __php__ namespace. As such, the file can be
expanded into this code:
new_file2.php:
<?php
namespace __php__;
include 'file1.php';
include 'file2.php';
$a = new PEAR2::DB;
$b = doSomething();
?>
On the last line, when PHP calls doSomething(), it first checks to see
if the function "doSomething" is available as an internal function.
Then, it tries __php__::doSomething() and fails on a fatal error because
the function does not exist. The only way that your idea would work is
if the check for "doSomething" consisted of checking for any
non-namespaced function (not just internal functions), but the sole
purpose of the fall-through is to allow users to call internal
functions/classes without explicitly specifying ::strlen or ::count and
so on. Allowing fall-through to any global class/function would serve
to dilute the namespacing effect, but perhaps this is a good thing? I
have not thought about this long enough to have a definitive opinion yet.
I think one safe way to handle this might be to have an E_STRICT if
class/function/const is declared in the __php__ namespace, so that PHP
provides a clear mechanism for enforcing the convention. Users wishing
to avoid this E_STRICT need only use another namespace name or adhere to
the coding convention of only putting stuff that uses code into the
__php__ namespace.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
