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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to