Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace

Jessie Hernandez wrote:

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,

right.

if not found, then they should be looked up in the global namespace,

never. I have no idea why do you think they should look there...

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.

Today all internal classes/functions are in the global namespace. We allowed usage of internal names in namespaces, because it would be terrible to prefix each usage of internal function like strlen(), write(). Dmitry.

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