Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33894
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <475CDE33.5010604@zend.com>
Date: Mon, 10 Dec 2007 09:35:31 +0300
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jessie Hernandez <jrhernandez05@gmail.com>
CC: internals@lists.php.net, Gregory Beaver <greg@chiaraquartet.net>
References: <93ED589E60BA254F97435FE6C97F2C6702B9222A@leedsmet-exch1.leedsmet.ac.uk> <475B4F1D.5060601@gmail.com> <475B90BF.2030801@chiaraquartet.net> <475C5CF5.4040008@gmail.com>
In-Reply-To: <475C5CF5.4040008@gmail.com>
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: dmitry@zend.com (Dmitry Stogov)



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
>