Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33885
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net
Message-ID: <475C5CF5.4040008@gmail.com>
Date: Sun, 09 Dec 2007 16:24:05 -0500
User-Agent: Thunderbird 1.5.0.12 (X11/20070530)
MIME-Version: 1.0
CC: Gregory Beaver <greg@chiaraquartet.net>
References: <93ED589E60BA254F97435FE6C97F2C6702B9222A@leedsmet-exch1.leedsmet.ac.uk> <475B4F1D.5060601@gmail.com> <475B90BF.2030801@chiaraquartet.net>
In-Reply-To: <475B90BF.2030801@chiaraquartet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
From: jrhernandez05@gmail.com (Jessie Hernandez)

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