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
> [EMAIL PROTECTED] 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
