Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33865
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sambarrow.com from 205.234.132.11 cause and error)
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
In-Reply-To: <200712071842.42282.larry@garfieldtech.com>
References: <alpine.DEB.0.98.0712042315260.20300@kossu.ez.no>
	 <00A2E2156BEE8446A81C8881AE117F199A06B9@companyweb>
	 <4759848D.5050007@chiaraquartet.net>
	 <200712071842.42282.larry@garfieldtech.com>
Content-Type: text/plain
Date: Sat, 08 Dec 2007 13:25:37 -0500
Message-ID: <1197138337.31333.8.camel@sams-room>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
From: sam@sambarrow.com (Sam Barrow)

In C++, STD was just a normal namespace with some classes and functions
in it, you didn't have to say "use std" unless you wanted to use
functions in the std namespace.

The "php::" namespace could just be a container for all of the functions
and classes that are currently thrown into the global namespace.

I think the name __php__ is too long and inconvenient to be used for a
namespace for all of the built in php functions. I would suggest "php::"
for built in php functions and "ext::<extension>::" for extension
defined functions.

On Fri, 2007-12-07 at 18:42 -0600, Larry Garfield wrote:
> On Friday 07 December 2007, Gregory Beaver wrote:
> 
> > > 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
> 
> Doesn't strict C++ also have a requirement for a global namespace definition?  
> It has been a very long time since I did any C++, but I seem to recall a 
> requirement for a "use std" or something like that directive that I never 
> actually understood. :-)
> 
> If there is a "named global namespace" __php__, then requiring it in order to 
> import anything makes sense.  It's one extra line of code and doesn't break 
> BC anymore than using the use keyword does.  
> 
> Another observation, if one takes the position that library code and "running 
> code" should always be separated, this setup would encourage that "best 
> practice" but does not absolutely require it.  That fits with the "doing 
> something dumb should be hard, but not impossible" philosophy. :-)  That 
> recommendation would definitely need to be well-documented.
> 
> I overall like this concept.  Kudos to Greg, as others have said.  One 
> question I would have is what is the performance hit of braces over a 
> keyword?  (Not a challenge; I genuinely don't know what the C implementation 
> differences would be that would make a difference.)  
> 
> -- 
> Larry Garfield			AIM: LOLG42
> larry@garfieldtech.com		ICQ: 6817012
> 
> "If nature has made any one thing less susceptible than all others of 
> exclusive property, it is the action of the thinking power called an idea, 
> which an individual may exclusively possess as long as he keeps it to 
> himself; but the moment it is divulged, it forces itself into the possession 
> of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
> Jefferson
>