Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33880
Return-Path: <greg@chiaraquartet.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 40932 invoked by uid 1010); 9 Dec 2007 06:52:43 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 40916 invoked from network); 9 Dec 2007 06:52:42 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 9 Dec 2007 06:52:42 -0000
Authentication-Results: pb1.pair.com header.from=greg@chiaraquartet.net; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=greg@chiaraquartet.net; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
X-PHP-List-Original-Sender: greg@chiaraquartet.net
X-Host-Fingerprint: 38.99.98.18 beast.bluga.net Linux 2.6
Received: from [38.99.98.18] ([38.99.98.18:56612] helo=mail.bluga.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 38/A6-13439-8B09B574 for <internals@lists.php.net>; Sun, 09 Dec 2007 01:52:41 -0500
Received: from mail.bluga.net (localhost.localdomain [127.0.0.1])
	by mail.bluga.net (Postfix) with ESMTP id 7B823C0E273;
	Sat,  8 Dec 2007 23:52:37 -0700 (MST)
Received: from [192.168.0.106] (CPE-76-84-15-179.neb.res.rr.com [76.84.15.179])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.bluga.net (Postfix) with ESMTP id 14970C0E256;
	Sat,  8 Dec 2007 23:52:36 -0700 (MST)
Message-ID: <475B90BF.2030801@chiaraquartet.net>
Date: Sun, 09 Dec 2007 00:52:47 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Jessie Hernandez <jrhernandez05@gmail.com>
CC: internals@lists.php.net
References: <93ED589E60BA254F97435FE6C97F2C6702B9222A@leedsmet-exch1.leedsmet.ac.uk> <475B4F1D.5060601@gmail.com>
In-Reply-To: <475B4F1D.5060601@gmail.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
From: greg@chiaraquartet.net (Gregory Beaver)

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