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
