Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33839
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <4759848D.5050007@chiaraquartet.net>
Date: Fri, 07 Dec 2007 11:36:13 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Matthias Pigulla <mp@webfactory.de>
CC: Derick Rethans <derick@php.net>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <alpine.DEB.0.98.0712042315260.20300@kossu.ez.no> <4758A390.4040402@chiaraquartet.net> <00A2E2156BEE8446A81C8881AE117F199A06B9@companyweb>
In-Reply-To: <00A2E2156BEE8446A81C8881AE117F199A06B9@companyweb>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
From: greg@chiaraquartet.net (Gregory Beaver)

Matthias Pigulla wrote:
>> 1) recommend all global non-namespaced code that wishes to import 
>> namespaced code via "use Namespace::Classname" add a "namespace 
>> __php__;" at the top of the file, and that the __php__ namespace be
>>  reserved for use by end-user applications.
> 
> 
>> 5) namespaces provide these benefits that are not available in PHP:
>>  a) short, unqualified descriptive class names can be used without 
>> fear of conflicting with an internal class
> 
> Interesting as I was not aware before that when a namespace is active
> the import goes into that namespace and not into global scope
> (clashing with core classes there).
> 
> But please consider:
> 
> -- Date.php -- <?php namespace __php__; class Date {} ?>
> 
> -- test.php -- <?php namespace __php__; require_once('autoload.php');
> // assume it would require Date.php when asked to do so print
> get_class(new Date()); ?>
> 
> Although this code has been future-proofed by adding the "namespace
> __php__", it will break if the core introduces a class named Date
> (will use the wrong class!). It also breaks without the namespace,
> and maybe it is a mistake to rely on autload here. But this is a case
> where using namespaces does not protect you from surprises unless you
> explicitly import ("use") all the classes you need. But that is not
> as simple as putting a namespace statement on top of all your files
> to be save.
> 
> If new, future core extensions showed up in a reserved PHP::
> namespace, you would be >:-).

Exactly - which is why you should never put classes, functions or
constants in the __php__ namespace.  The convention I am proposing is to
only use __php__ for code that *uses* re-usable components, not
*declares* them.  In this case, your example would be revised as:

<?php
namespace Mylib;
class Date {}
?>

<?php
namespace __php__;
use Mylib::Date;
include 'autoload.php'; // note - require_once and () just slow things down
$a = new Date();
?>

This convention serves two purposes

1) library code is always explicitly "use"d
2) name conflicts are impossible

The suggestion to make "namespace __php__;" implicit is very
interesting, but would defeat its purpose, which is to separate
declarations from use.

Another off-list suggestion was to make "use" outside of a namespace
declaration an error, as this is generally a bad idea that can lead to
many "gotchas".

Greg