RFC: Dropping Namespace View as Markdown

I think namespaces are very useful when it comes to PHP in large scale
applications with hundreds of functions/classes.

With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for myself
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I
have totally no problem with, as it is nice and easy.

I hate to, but I agree. If the only point is to make class naming
pretty, it is kind of pointless. Give me namespaces that scope
variables to a file and then we have something. Yeah, I still code the
way PHP intended you to code, by templateing files together and not
making gynormous classes to print out some simple HTML over and over.

It would only be useful in that my company's code would not conflict
with some 3rd party software we use.

--

Brian Moon
Senior Developer

http://dealnews.com/
It's good to be cheap =)

Hi D,

extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:

<?php
use myNamespace::DateTimeZone as DateTimeZone;
?>

Typo? I guess you meant 'DateTimeSpan' to be in there somewhere...

This is I think the biggest problem with the implementation, that new
internal classes can still break userland code. The problem of single-file
namespacing is only a problem because of the performance implications for
those who bundle their includes, and it should be possible to find a good
way to resolve that. I don't really see a problem with the 'use only at the
head of the file' thing (although I know others do); in fact I prefer it,
because it makes for an easier upgrade path.

Can I just ask one thing? If namespace support is once again pulled before
it sees the light of a release, can we please document exactly what the
problems were, loud and clear, and put the document somewhere people are
likely to see it?

Thanks,

• Steph

--

I never thought it would get back to the drawing board that way, but
Derick, as I said on irc when we discussed about that, I agree with
you. With the current implementation, the namespaces should be removed
completely. Not only because it has missing features, but from the
voice that comes out of the community, it seems that some features
(important ones) (Point 2) and some PHP general concept (Point 3) are
simply not what people want.

I do not want to start a flamewar here, but again, the { } thread came
up a few days ago and again, everyone who says that they get a
performance gain by aggregating the files (Like compiled PHP files)
are being either ignored or in some way insulted... Anyways, some
people do not believe in the aggregation of the files, why's that ? I
am not quite sure, well I have a few ideas but they are not
appropriate for the mailing list, but the optimization technique that
is aggregating the files work and I would really love to see it stay
(At least the ability to decide if I want to aggregate them or not).
And this is currently not possible with the implementation.

Things like use * as * is something that is missing and a very
important feature to my eyes as well. However, this kind of feature
comes with education. If we allow people to use * as *, we have to
explain them that the namespaces are not going to be coding for you.
They might introduce the same conflicting errors as before when they
had only classes. I want to make sure people understand that
namespaces are not there to make one type less but as a great man once
said, an additional structural element that is to be used correctly in
order to work correctly.

(You can give a nail to someone and he'll stick it in his eye instead
of building a house... but if you show him how to use the nail
correctly and with which other tools, he'll be able to build something
solid... maybe...)

From what I have experienced since the namespaces are in, my prefixing
is still the way to go to make sure I can run all my nifty
optimization scripts around and make a few "free" optimizations.

This is a thread that will probably go deep in the sand in a few days
(unless the community arises (which doesn't usually happen)) but for
the records, if anyone has anything to say, it's still the time :)

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

Can I just ask one thing? If namespace support is once again pulled
before it sees the light of a release, can we please document
exactly what the problems were, loud and clear, and put the
document somewhere people are likely to see it?

Amen. I wish we would do that for every decision we make that was
remotely controversial. Such summaries should link together all
relevant posts with a short summary. This is what I was talking about
before I left for Brazil. I think taking the approach to tag posts +
then being able to write some commentary would be a good solution for
this that could work out without too much reliance on a single person
putting in a fixed amount of time per week.

regards,
Lukas

However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.

This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global space you'd work with existing name
xmlreader, which would be redefined. And PHP never allowed redefining
classes.

file1.php:
<?php
class DB {}
?>

file2.php:
<?php
import DB as Other_DB;
include 'file1.php';
class DB extends Other_DB {}
?>

You mean 'use' should kill the old name? I don't think it's a good idea

• we'd have to keep track of killed names, and since class can be named
  in a lot of ways - i.e. if you have name A::B::C::D you can alias any
  part of name, it would become messy.

Why exactly you need to rename existing classes?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.

No, use should not allow this. Take the following example:

<?php
namespace blah;
use DomDocument as test;

class DOMDocument { }

$dom = new DOMDocument; //
$dom->loadXML('<books><book><title>blah</title></book></books>');
$s = simplexml_import_dom($dom);

echo $s->book[0]->title; // blah
?>

Besides this being a big WTF factor (why is my internal class
suddendly doing something else?) simplexml will horrible fail in this
case.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

following some discussions on the list (re. multiple namespaces in file) as
well as a short discussion on IRC regarding not being able to do
"use yeti::xml::DomDocument as DomDocument;" - I do not see any point in
having

You mean like ability to override existing classes? I think it could be done
but I don't see it as a good idea - it probably would lead to some weird
programming mistakes.

Of course, I think allowwing this is a really bad idea - which brings me
to the main point of this argument:

1. As it is impossible to do "use XXX as NativeClass" we get to the point
   where we'd have to namespace new internal native classes
   otherwise we might introduce BC breaks. AFAIK, we've always said that

There's very easy solution to this, if it ever becomes a problem - using
two-component names.

And that is exactly what I think we should not do. PHP reserves the
global scope. period. That means that (core)extensions should not have
to deal with all sorts of namespace clue or other tricks just because
some people like a "misguided" implementation of namespaces. The idea of
namespaces is to prevent collisions in USER land code, not turning
internal PHP classes into a pile of goo.

3. We keep bickering over using { } or not, multiple namespaces in a
   file or not... etc. I understand that people want more flexibility,
   but also we need a simple to explain implementation. With the

That's why not all flexibility gets in.

• You can't stick multiple namespaces in one file

You are not supposed to unless you using it as performance solution, which is
rather dubious practice anyway.

You're not supposed to put a count($array) inside your for loop either.
I don't quite understand why allowing multiple namespaces is such a big
issue, however - it won't solve the naming collision issue.

• Unlike other constructs in PHP that mark executable blocks,
  namespaces don't use { }.

That's because namespaces are not executable blocks.

Neither are classes.

4. What is wrong with simple prefixes in the first place? Both PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for different
   'namespaces'. We could optionally create a registry on php.net for
   this to avoid conflicts.

What is wrong is names like
PEAR_DB_Data_Database_Module_Adapter_Implementation_Interface_Exception_Information_Collection_Element.
When you write a code that uses such names, you really don't want to repeat
all the thing every time.

No, but, do you really need to have such long names? And besides that,
you have to keep repeating them in every file you'd want to use them -
which means you actually have to type more in some places. So this
argument is kind of lame.

useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for
myself

Yes, they are.

Just saying "Yes, they are" is not a very good argument - actually, it's
not an argument at all.

(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I

Well, the loss is all yours :)

Actually, it's exactly the opposite, as I avoid naming colissions
(point 1), I don't need to import every class I want to use (point 2),
and can group all my classes together in one file (point 3).

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

4. What is wrong with simple prefixes in the first place? Both PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for different
   'namespaces'. We could optionally create a registry on php.net for
   this to avoid conflicts.

Although most people on the list seem to be coming at this problem assuming
classes, I want to offer a counter-example that is all functions.

In Drupal, our plugin architecture is based on function naming. When a given
event "omg" occurs, something akin to the following frequently happens (a bit
simplified):

$hook = 'omg';
foreach ($modules_that_are_loaded as $module) {
$function = $module .'_'. $hook;
if (function_exists($function)) {
$return[] = $function();
}
}
return $return;

It's a very powerful mechanism, and quite flexible. The one thing it doesn't
offer is, given a function name, determine what module and hook/event it is
for. That's because we use PHP core coding standards, which say to use
function_name for all functions. So given this function name:

views_do_stuff()

Is that the "do stuff" hook from the "views" module/plugin, or the "stuff"
hook from the "views_do" module? Excellent question, and one that cannot be
reliably solved. (There is a module called "views", but nothing is stopping
anyone from writing a "views_do" module and declaring their own "stuff"
hook.)

<?php

$hook = 'omg';
foreach ($modules_that_are_loaded as $module)
{
$function = $module .'__'. $hook;
if (function_exists($function))
{
$return[] = $function();
}
}
return $return;

?>

There ye have it!

<?php

list( $module, $hook ) = explode( '__', $function );

?>

Namespace support is for people who didn't name their classes/functions
properly. I'm not for or against it.

Cheers,
Rob.

...........................................................
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!

...........................................................

Hi Larry,

namespace me;
use Whatever as LegacyWhatever;
class Whatever{}

I'd missed that in the ebb and flow. I guess the bug in my copy was fixed
then, good. It still doesn't make sense to have global import though...?

(I'm probably going to kick myself sooo hard for this in the morning...)

• Steph

I think support for multiple namespaces in one file should definitely be
used. As far as using curly braces vs using the namespace declaration,
it doesn't really matter to me, however it is important that i be able
to use the same namespace twice:

namespace a {
function function1() {
return true ;
}
}

// some other code

namespace a {
function function2() {
return false ;
}
}

1. "use MyDate as DateTime". I believe Greg pointed out the solution here.
   When PHP 5.5 is released and adds its own Whatever class, you just do the
   following:

namespace me;
use Whatever as LegacyWhatever;
class Whatever{}

It's a one-line change to keep your code working. I think that's acceptable,

It's not acceptable, as you're breaking BC.

For whatever the opinion of someone who writes PHP all day and not C
is worth, there it is.

What makes you think I am different?

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

Hi Derick,
I also agree with your arguments - beautifying class names is not
reason enough for
introducing namespaces.
On 04.12.2007 at 23:16 Derick Rethans wrote:

4. What is wrong with simple prefixes in the first place? Both
   PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for
   different
   'namespaces'. We could optionally create a registry on php.net for
   this to avoid conflicts.

While experimenting with namespaces to use with the next major
version of
TYPO3, I realized that always using a full class name such as

"T3_MyPackage_MySubPackage_Controller_DefaultController"

has many advantages. Autoloading becomes a lot easier and if the
filename
equals the class name (ie. the full name, not only
"DefaultController.php")
you are never in doubt where a file belongs to or comes from.

Therefore we in the TYPO3 project currently tend to not using
namespaces
even if PHP6 had support for them.

Wow, total Deja Vu.

http://www.phpbuilder.com/lists/php-documentation-list/2001071/0109.php

I, for one, would not enjoy typing out:
"T3_MyPackage_MySubPackage_Controller_DefaultController" any more
often than I absolutely had to. And in a somewhat amusing sense,
the "register_global" vs. "local variable" debates aren't that far
off from "register_class_as_global" vs. "local class namespace"
debates....

Maybe we could all just re-read the email archives from back then,
and save ourselves a lot of arguing?

:)

-Bop

Autoload would work exactly the same with namespaces, just do a
str_replace and replace "::" with "_".

Hi Derick,

I also agree with your arguments - beautifying class names is not
reason enough for
introducing namespaces.

On 04.12.2007 at 23:16 Derick Rethans wrote:

4. What is wrong with simple prefixes in the first place? Both PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for
   different
   'namespaces'. We could optionally create a registry on php.net for
   this to avoid conflicts.

While experimenting with namespaces to use with the next major version
of
TYPO3, I realized that always using a full class name such as

"T3_MyPackage_MySubPackage_Controller_DefaultController"

has many advantages. Autoloading becomes a lot easier and if the
filename
equals the class name (ie. the full name, not only
"DefaultController.php")
you are never in doubt where a file belongs to or comes from.

Therefore we in the TYPO3 project currently tend to not using namespaces
even if PHP6 had support for them.

robert

I agree. If the solution to this is to start adding prefixes to the aliased
names, then namespaces lose part of their purpose.

The solution is not to import everything in global space. If you must,
namespaces as such won't help you avoid collisions. The purpose of
namespaces is NOT (I don't know how to make it more clear - should I
use blinking text, flash graphics and pictures of dancing girls/boys in
bikinis?) - it is NOT to allow you shoving all your library classes
into global space and in some magic way make same names mean different
classes by telepathically reading your mind. The purpose of namespaces
is to make working with long names - necessary to avoid collisions -
easier, by enabling not always use the whole long name but sometimes
only a part of it.

Globbing of this nature, in my humbled opinion, would not be the best idea
because of the high potential of problems. But, in the same respect, with

That's exactly why it was dropped. More precisely, it is one of the
reasons - other being it would break lookup performance and bytecode
caches.

I think this is a huge issue, if only for consistency with other constructs
of the language. There are already three different ways to write an

Guys, really, how many times should we beat this particular dead horse?

The only difference, on the surface, that I see with namespaces vs. standard
prefixing is that namespaces has a new keyword and changes the separator
from an underscore to the double colon. Beyond that, without the other

Well, I think reading the actual docs would help to see more. Besides
that, namespaces allow aliasing of prefixes and automatic prefixing.

For what it's worth, I would have to completely agree with Derick on this
issue. It just seems that namespaces could be made to do much more than it
already does.

Leaving braces aside (please!), what capabilities that were not
discussed before do you need?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Holy wow. That was fantastic! Not to downplay anything that Stas and the
other developers have done -- because let's face it, they've done a
fantastic job themselves -- you have definitely risen above and beyond the
call of duty and really come up with some very compelling counter-arguments.
This really makes me look forward to using namespaces, and to reading your
guides. Thank you for all of the time and effort you, and those who have
spent time helping you, have put into this feature. :)

Hi Greg,

Thanks for the detailed thoughts.
Guides & examples regarding use-cases will definitely be important for the community. I am sure just this email has already been very helpful to many on this list.

Andi

-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Thursday, December 06, 2007 5:36 PM
To: Derick Rethans
Cc: PHP Developers Mailing List
Subject: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace

Hi Derick,

I've been thinking a lot about your provocative email in the past
couple of days, and have come to a different conclusion from my
original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). After a few hours of thinking practically about the
implementation, I realized that this would be impossible for the same
reasons as your first argument. So, I set out to find a solution that
keeps namespaces and solves the problems.

I have found the solutions to every problem I could find, and to my
surprise, even after crafting a new patch to solve some of them, have
found a way to solve all of the problems within the existing
implementation (with a few tweaks, but nothing major changed) or by
specifying new coding conventions.

Summary:

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.
2. use Name::*; is technically impossible without some kind of
   autoloading mechanism, but can be reasonably approximated by importing
   a
   long namespace name as a shorter one. "use PEAR2::Really::Long::Name
   as
   a;" then allows referring to PEAR2::Really::Long::Name::Classname as
   a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as
   a::Subnamespace::Classname.
3. multiple namespaces per file should be allowed, but strongly
   discouraged as a coding practice of last resort for most users.
4. brackets for namespaces is most necessary for hierarchical namespace
   implementations. This is not such an implementation, and as such
   brackets do not add clarity but do slow down the implementation.
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
   b) a clear, uniform coding convention on how to avoid conflicts
   between your code and others that will help those who have to maintain
   the code of others.
   c) a way to alias longer names to increase readability and
   maintainability of code.
6. There are some dangers when using namespaces with autoload, but
   simple ways of thwarting those dangers. Also dangerous is trusting
   external code that is in the same namespace, as functions can be
   redefined.

Detailed answers:

Derick Rethans wrote:

1. As it is impossible to do "use XXX as NativeClass" we get to the

<snip> > extension (DateTime, DateTimeZone). However introducing the new class > DateTimeSpan might break people's code that do things like: > > &lt;?php > use myNamespace::DateTimeZone as DateTimeZone; > ?>

This is indeed the biggest problem. However, it only exists in the
global "namespace" (non-namespaced code). An example script using the
non-existing hypothetical PEAR2::DateTime class:

<?php
include 'PEAR2/Autoload.php';
use PEAR2::DateTime; // fatal error - use name conflicts with internal
class
$a = new DateTime;
?>

However, the answer is simple and elegant. PHP applications that take
advantage of namespaces should use a namespace in the application
global code that is reserved for application code, like php.

<?php
namespace php;
include 'PEAR2/Autoload.php';
use PEAR2::DateTime;
$a = new DateTime; // $a is an object of class PEAR2::DateTime after
autoloading, or if a previously included file has declared class
DateTime in namespace PEAR
?>

Note that the only difference here is the addition of 1 line of code at
the top of the file. On the same token, this code:

<?php
namespace php;
$a = new DateTime; // $a is an object of class ::DateTime
?>

works as expected, accessing the internal DateTime class directly.

In other words, 1 line of code is needed to take advantage of
namespace's full protection and ability to import conflicting class
names into the "global" (in this case unqualified, not containing :: in
the name) scope, while at the same time preserving BC with existing
code
(no modification needed beyond addition of "namespace php;").

I recommend that the manual specify this convention, and will happily
take on the documentation of it.

2. You have to import every class yourself. You can currently not do:

   use myNamespace::* as *; // or similar syntax

Actually, ::* would only be deterministic if use performed some kind of
autoloading, it's not a question of runtime versus compile-time - it's
simply not possible to determine which class is intended if more than
one ::* is used unless the answer is determined by code loading, this
is
why Java/Python import actually loads code as well as aliasing
identifiers.

There are ways of simulating "use myNamespace::* as *;" that are almost
as complete and are actually better for long-term maintenance. For
instance, let's say you want to use several classes from
PEAR2::Ultra::Long::Package::Name. You don't need to use each class
individually, you can import the entire namespace:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name;
$a = new Name::ExampleClass;
$b = new Name::SecondThing;
$c = new Name::ThirdThing;
?>

or the ultra-brief method, requiring 3 extra characters over an
unqualified name:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
?>

Even more significant, you can use sub-namespaces with this system,
each
namespace does not need to be imported separately:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass; // $d is an object of class
PEAR2::Ultra::Long::Package::Name::subnamespace::MyClass
?>

This is dramatically easier to debug than the equivalent import of ::*
(with an added namespace for dramatic effect):

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name::;
use Symfony::Something::;
$a = new ExampleClass;
$b = new SecondThing;
$c = new ThirdThing;
$d = new subnamespace::MyClass;
$e = new Controller; // which package is this class from?
?>

Looking at the code, it is impossible to determine which package the
classes come from. Here is the same example with current syntax:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
use Symfony::Something as s;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass;
$e = new s::Controller; // now we know for certain this is from Symfony
?>

3. We keep bickering over using { } or not, multiple namespaces in a
   file or not... etc. I understand that people want more
   flexibility,
   but also we need a simple to explain implementation. With the
   current implementation I see the following problems here:

   • You can't stick multiple namespaces in one file
   • Unlike other constructs in PHP that mark executable blocks,
     namespaces don't use { }.
   • The "namespace" keyword at the start of a file is somewhat
     magic,
     because it can only appear as first element in your script.

I have wrestled with this many times, and the best conclusion I can
reach is that (1) we need the flexibility of multiple namespaces per
file, but that (2) we need to strongly discourage it for the reason
that it is going to make debugging harder. There are two valid use
cases for multiple namespaces per file that I have encountered:

1. performance. PHP is slightly slower when executing stuff in
   multiple
   files
2. GTK2. It's always nice to be able to put a GTK2 app in a single
   file
   and this is an alternative to using a phar archive.

There are two philosophies behind namespaces out there, hierarchical
and
non-hierarchical. In hierarchical languages like C++ and C#, nested
namespaces can be defined, and sub-namespaces can be defined using
nested code blocks. Other implementations simply don't do this. The
best description I've seen is from a site on Perl namespaces:

"Isaac Newton is not related to Olivia Newton-John, and Newton::Isaac
is
not related to Newton::John::Olivia."

Perl, incidentally, uses the package keyword as a combination of
declaration and alias, in that there is no equivalent to PHP's use.

PHP's implementation is a mixture of these approaches. Because it is
closer to Perl's implementation of package, but contains the import
statement from compiled languages like C++, we have to forge a new
path.

Having namespace as the start of the file is good because it enforces a
declaration "take note: this file uses namespaces" that might otherwise
be lost.

I have no strong opinion on {}, but I do see a compelling argument in
favor of not using {} for performance reasons if you're only going to
use 1 namespace per file except in extraordinary circumstances.

4. What is wrong with simple prefixes in the first place? Both
   PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for
   different
   'namespaces'. We could optionally create a registry on php.net
   for
   this to avoid conflicts.

The only naming conflicts we've had have been with internal classes
thus
far, but there is no coding convention in place. Namespaces would
provide a technical solution to a political problem, something that
carries with it intrinsic risks. Fortunately, other languages have
taken this risk before PHP and not had major problems, so we have a
reasonable expectation of success. The implementations of namespacing
vary so widely, it's kind of impossible to generalize on how they do
it,
but difference between prefixing and namespaces can be exemplified by
one construct: use.

<?php
// assume we've loaded code for brevity
$a = Zend_Long_Class_Name::singleton(Zend_Long_Class_Name::CONST);
$b = new PEAR2_Long_Class_Name();
Zend_Long_Class_Name::$var = 2;
?>

<?php
namespace php;
use Zend::Long::Class as a;
use PEAR2::Long::Class as b;
$a = a::Name::singleton(a::Name::CONST);
$b = new b::Name();
a::Name::$var = 2;
?>

Also possible with namespaces is switching out an implementation with a
similar API without search/replace (assuming no dynamic class
references
are used)

<?php
// before
namespace php;
use Zend::Thing::Implementation;
$a = new Implementation;
?>

<?php
// after
namespace php;
use PEAR2::Does::Same::Thing as Implementation;
$a = new Implementation;
?>

With all the above considerations, especially my first point, I still
have not
heard any good reason why namespaces in the current implementation
are actually
useful - or what particular case they solve... so I am wondering, are
they
really useful? I come now to the conclusion that they are not, and
for myself
(and most likely my work projects) I would have to decide not to go
with
namespaces, but instead stick with the 3 letter prefixing. Something
that I
have totally no problem with, as it is nice and easy.

1. The ability to guarantee short names can be used without danger of
   conflicting with a global name. This is possible inside any namespace
   declaration, but not in global scope.

2. readability, and therefore maintainability increases as redundant
   parts of identifiers are removed by use aliasing. This line:

<?php
return new PEAR2_Pyrus_PackageFile_v2Iterator_File(
new
PEAR2_Pyrus_PackageFile_v2Iterator_FileAttribsFilter(
new
PEAR2_Pyrus_PackageFile_v2Iterator_FileContents(
$this->packageInfo['contents'], 'contents',
$this)),
RecursiveIteratorIterator::LEAVES_ONLY);
?>

becomes:

<?php
use PEAR2::Pyrus::PackageFile::v2Iterator as i2;
use ::RecursiveIteratorIterator as ri; // currently not possible in CVS
but I have a patch...
// ...

            return new i2::File(
                    new i2::FileAttribsFilter(
                    new i2::FileContents(
                        $this->packageInfo['contents'], 'contents',

$this)),
ri::LEAVES_ONLY);
?>

The argument has been made that namespaces can actually increase code
size because class names are so rarely used. This is not true in my
coding experience. As an example, a single file in PEAR2_Pyrus has 25
uses of the classname PEAR2_Pyrus_PackageFile_Exception. Any class
making use of class constants used by another class will be using the
full classname a lot.

3. Ability to use common short names (like File, Exception, Date) as
   class names within a namespace increases the logical descriptive
   qualities of the code, making it easier to understand without
   documentation (self-documenting code). For example, in the classname
   PEAR2::Pyrus::Config, the only part that really describes anything
   important for the user to know about is "Config", the rest is
   redundant.

In terms of the danger of using namespaced classes with autoload, the
biggest danger is this code:

<?php
namespace Blah;
$a = new Exception('hi');
?>

In this case, the ::Exception class is instantiated.

<?php
namespace Blah;
use Blah::Exception;
$a = new Exception('hi');
?>

Now we guarantee the correct class is loaded. Although this seemed
onerous to me at first, on reflection, there are very few internal
classes that are likely to be overridden by a package (only 98 exist in
my 5.3 build), probably at most 2 in any given package, so this is not
a
huge burden.

A larger danger is this example:

<?php
namespace foo;
echo strlen('hi');
include 'maliciousfile.php';
echo strlen('hi');
?>

maliciousfile.php:
<?php
namespace foo;
function strlen($a)
{
// do bad stuff
echo "I'm evil"
return ::strlen($a);
}
?>

The above script outputs "2I'm evil2" - foo::strlen() is called for the
second call to strlen(). Application authors like blogs that run
plugins must be extremely cautious that plugins from third parties
cannot contain redefinitions of core functions inside the blog's
namespace. Of course, any third-party code is dangerous regardless of
language construct, but this is a subtle vector that could be used and
would not be caught by a code scanner unless consciously coded in to
watch for a "namespace foo;" declaration.

I hope this is helpful - by digging deeply into the source and talking
to lots of devs, I have learned a lot about PHP's namespace
implementation in the past 2 days, and I'm certain we have a much
better
implementation than I thought we did 2 days ago, and will be writing up
a "how to namespace" and "how not to namespace" guide based on the
pitfalls I've discovered in this quest as well as contributing to the
documentation when things settle.

Greg

Hi Greg,

I'm speechless. All of your points are sound and you've obviously done
your homework, here. I agree with Ken in that you've gone above and
beyond on the research and arguments you've presented here.

Excellent work and a hearty +1 to all of your points.

Jeremy

Gregory Beaver wrote:

Hi Derick,

I've been thinking a lot about your provocative email in the past
couple of days, and have come to a different conclusion from my original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). After a few hours of thinking practically about the
implementation, I realized that this would be impossible for the same
reasons as your first argument. So, I set out to find a solution that
keeps namespaces and solves the problems.

I have found the solutions to every problem I could find, and to my
surprise, even after crafting a new patch to solve some of them, have
found a way to solve all of the problems within the existing
implementation (with a few tweaks, but nothing major changed) or by
specifying new coding conventions.

Summary:

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.
2. use Name::*; is technically impossible without some kind of
   autoloading mechanism, but can be reasonably approximated by importing a
   long namespace name as a shorter one. "use PEAR2::Really::Long::Name as
   a;" then allows referring to PEAR2::Really::Long::Name::Classname as
   a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as
   a::Subnamespace::Classname.
3. multiple namespaces per file should be allowed, but strongly
   discouraged as a coding practice of last resort for most users.
4. brackets for namespaces is most necessary for hierarchical namespace
   implementations. This is not such an implementation, and as such
   brackets do not add clarity but do slow down the implementation.
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
   b) a clear, uniform coding convention on how to avoid conflicts
   between your code and others that will help those who have to maintain
   the code of others.
   c) a way to alias longer names to increase readability and
   maintainability of code.
6. There are some dangers when using namespaces with autoload, but
   simple ways of thwarting those dangers. Also dangerous is trusting
   external code that is in the same namespace, as functions can be redefined.

Detailed answers:

Derick Rethans wrote:

1. As it is impossible to do "use XXX as NativeClass" we get to the

<snip>

extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:

<?php
use myNamespace::DateTimeZone as DateTimeZone;
?>

This is indeed the biggest problem. However, it only exists in the
global "namespace" (non-namespaced code). An example script using the
non-existing hypothetical PEAR2::DateTime class:

<?php
include 'PEAR2/Autoload.php';
use PEAR2::DateTime; // fatal error - use name conflicts with internal class
$a = new DateTime;
?>

However, the answer is simple and elegant. PHP applications that take
advantage of namespaces should use a namespace in the application
global code that is reserved for application code, like php.

<?php
namespace php;
include 'PEAR2/Autoload.php';
use PEAR2::DateTime;
$a = new DateTime; // $a is an object of class PEAR2::DateTime after
autoloading, or if a previously included file has declared class
DateTime in namespace PEAR
?>

Note that the only difference here is the addition of 1 line of code at
the top of the file. On the same token, this code:

<?php
namespace php;
$a = new DateTime; // $a is an object of class ::DateTime
?>

works as expected, accessing the internal DateTime class directly.

In other words, 1 line of code is needed to take advantage of
namespace's full protection and ability to import conflicting class
names into the "global" (in this case unqualified, not containing :: in
the name) scope, while at the same time preserving BC with existing code
(no modification needed beyond addition of "namespace php;").

I recommend that the manual specify this convention, and will happily
take on the documentation of it.

2. You have to import every class yourself. You can currently not do:

   use myNamespace::* as *; // or similar syntax

Actually, ::* would only be deterministic if use performed some kind of
autoloading, it's not a question of runtime versus compile-time - it's
simply not possible to determine which class is intended if more than
one ::* is used unless the answer is determined by code loading, this is
why Java/Python import actually loads code as well as aliasing identifiers.

There are ways of simulating "use myNamespace::* as *;" that are almost
as complete and are actually better for long-term maintenance. For
instance, let's say you want to use several classes from
PEAR2::Ultra::Long::Package::Name. You don't need to use each class
individually, you can import the entire namespace:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name;
$a = new Name::ExampleClass;
$b = new Name::SecondThing;
$c = new Name::ThirdThing;
?>

or the ultra-brief method, requiring 3 extra characters over an
unqualified name:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
?>

Even more significant, you can use sub-namespaces with this system, each
namespace does not need to be imported separately:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass; // $d is an object of class
PEAR2::Ultra::Long::Package::Name::subnamespace::MyClass
?>

This is dramatically easier to debug than the equivalent import of ::*
(with an added namespace for dramatic effect):

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name::;
use Symfony::Something::;
$a = new ExampleClass;
$b = new SecondThing;
$c = new ThirdThing;
$d = new subnamespace::MyClass;
$e = new Controller; // which package is this class from?
?>

Looking at the code, it is impossible to determine which package the
classes come from. Here is the same example with current syntax:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
use Symfony::Something as s;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass;
$e = new s::Controller; // now we know for certain this is from Symfony
?>

3. We keep bickering over using { } or not, multiple namespaces in a
   file or not... etc. I understand that people want more flexibility,
   but also we need a simple to explain implementation. With the
   current implementation I see the following problems here:

   • You can't stick multiple namespaces in one file
   • Unlike other constructs in PHP that mark executable blocks,
     namespaces don't use { }.
   • The "namespace" keyword at the start of a file is somewhat magic,
     because it can only appear as first element in your script.

I have wrestled with this many times, and the best conclusion I can
reach is that (1) we need the flexibility of multiple namespaces per
file, but that (2) we need to strongly discourage it for the reason
that it is going to make debugging harder. There are two valid use
cases for multiple namespaces per file that I have encountered:

1. performance. PHP is slightly slower when executing stuff in multiple
   files
2. GTK2. It's always nice to be able to put a GTK2 app in a single file
   and this is an alternative to using a phar archive.

There are two philosophies behind namespaces out there, hierarchical and
non-hierarchical. In hierarchical languages like C++ and C#, nested
namespaces can be defined, and sub-namespaces can be defined using
nested code blocks. Other implementations simply don't do this. The
best description I've seen is from a site on Perl namespaces:

"Isaac Newton is not related to Olivia Newton-John, and Newton::Isaac is
not related to Newton::John::Olivia."

Perl, incidentally, uses the package keyword as a combination of
declaration and alias, in that there is no equivalent to PHP's use.

PHP's implementation is a mixture of these approaches. Because it is
closer to Perl's implementation of package, but contains the import
statement from compiled languages like C++, we have to forge a new path.

Having namespace as the start of the file is good because it enforces a
declaration "take note: this file uses namespaces" that might otherwise
be lost.

I have no strong opinion on {}, but I do see a compelling argument in
favor of not using {} for performance reasons if you're only going to
use 1 namespace per file except in extraordinary circumstances.

4. What is wrong with simple prefixes in the first place? Both PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for different
   'namespaces'. We could optionally create a registry on php.net for
   this to avoid conflicts.

The only naming conflicts we've had have been with internal classes thus
far, but there is no coding convention in place. Namespaces would
provide a technical solution to a political problem, something that
carries with it intrinsic risks. Fortunately, other languages have
taken this risk before PHP and not had major problems, so we have a
reasonable expectation of success. The implementations of namespacing
vary so widely, it's kind of impossible to generalize on how they do it,
but difference between prefixing and namespaces can be exemplified by
one construct: use.

<?php
// assume we've loaded code for brevity
$a = Zend_Long_Class_Name::singleton(Zend_Long_Class_Name::CONST);
$b = new PEAR2_Long_Class_Name();
Zend_Long_Class_Name::$var = 2;
?>

<?php
namespace php;
use Zend::Long::Class as a;
use PEAR2::Long::Class as b;
$a = a::Name::singleton(a::Name::CONST);
$b = new b::Name();
a::Name::$var = 2;
?>

Also possible with namespaces is switching out an implementation with a
similar API without search/replace (assuming no dynamic class references
are used)

<?php
// before
namespace php;
use Zend::Thing::Implementation;
$a = new Implementation;
?>

<?php
// after
namespace php;
use PEAR2::Does::Same::Thing as Implementation;
$a = new Implementation;
?>

With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for myself
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I
have totally no problem with, as it is nice and easy.

1. The ability to guarantee short names can be used without danger of
   conflicting with a global name. This is possible inside any namespace
   declaration, but not in global scope.

2. readability, and therefore maintainability increases as redundant
   parts of identifiers are removed by use aliasing. This line:

<?php
return new PEAR2_Pyrus_PackageFile_v2Iterator_File(
new
PEAR2_Pyrus_PackageFile_v2Iterator_FileAttribsFilter(
new PEAR2_Pyrus_PackageFile_v2Iterator_FileContents(
$this->packageInfo['contents'], 'contents',
$this)),
RecursiveIteratorIterator::LEAVES_ONLY);
?>

becomes:

<?php
use PEAR2::Pyrus::PackageFile::v2Iterator as i2;
use ::RecursiveIteratorIterator as ri; // currently not possible in CVS
but I have a patch...
// ...

            return new i2::File(
                    new i2::FileAttribsFilter(
                    new i2::FileContents(
                        $this->packageInfo['contents'], 'contents',

$this)),
ri::LEAVES_ONLY);
?>

The argument has been made that namespaces can actually increase code
size because class names are so rarely used. This is not true in my
coding experience. As an example, a single file in PEAR2_Pyrus has 25
uses of the classname PEAR2_Pyrus_PackageFile_Exception. Any class
making use of class constants used by another class will be using the
full classname a lot.

3. Ability to use common short names (like File, Exception, Date) as
   class names within a namespace increases the logical descriptive
   qualities of the code, making it easier to understand without
   documentation (self-documenting code). For example, in the classname
   PEAR2::Pyrus::Config, the only part that really describes anything
   important for the user to know about is "Config", the rest is redundant.

In terms of the danger of using namespaced classes with autoload, the
biggest danger is this code:

<?php
namespace Blah;
$a = new Exception('hi');
?>

In this case, the ::Exception class is instantiated.

<?php
namespace Blah;
use Blah::Exception;
$a = new Exception('hi');
?>

Now we guarantee the correct class is loaded. Although this seemed
onerous to me at first, on reflection, there are very few internal
classes that are likely to be overridden by a package (only 98 exist in
my 5.3 build), probably at most 2 in any given package, so this is not a
huge burden.

A larger danger is this example:

<?php
namespace foo;
echo strlen('hi');
include 'maliciousfile.php';
echo strlen('hi');
?>

maliciousfile.php:
<?php
namespace foo;
function strlen($a)
{
// do bad stuff
echo "I'm evil"
return ::strlen($a);
}
?>

The above script outputs "2I'm evil2" - foo::strlen() is called for the
second call to strlen(). Application authors like blogs that run
plugins must be extremely cautious that plugins from third parties
cannot contain redefinitions of core functions inside the blog's
namespace. Of course, any third-party code is dangerous regardless of
language construct, but this is a subtle vector that could be used and
would not be caught by a code scanner unless consciously coded in to
watch for a "namespace foo;" declaration.

I hope this is helpful - by digging deeply into the source and talking
to lots of devs, I have learned a lot about PHP's namespace
implementation in the past 2 days, and I'm certain we have a much better
implementation than I thought we did 2 days ago, and will be writing up
a "how to namespace" and "how not to namespace" guide based on the
pitfalls I've discovered in this quest as well as contributing to the
documentation when things settle.

Greg

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 >:-).

-mp.

Great work!

+1 from me for your proposals, too!

Roman

Hi Derick,

I've been thinking a lot about your provocative email in the past
couple of days, and have come to a different conclusion from my
original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). After a few hours of thinking practically about the
implementation, I realized that this would be impossible for the same
reasons as your first argument. So, I set out to find a solution that
keeps namespaces and solves the problems.

I have found the solutions to every problem I could find, and to my
surprise, even after crafting a new patch to solve some of them, have
found a way to solve all of the problems within the existing
implementation (with a few tweaks, but nothing major changed) or by
specifying new coding conventions.

Summary:

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.
2. use Name::*; is technically impossible without some kind of
   autoloading mechanism, but can be reasonably approximated by
   importing a
   long namespace name as a shorter one. "use
   PEAR2::Really::Long::Name as
   a;" then allows referring to PEAR2::Really::Long::Name::Classname as
   a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as
   a::Subnamespace::Classname.
3. multiple namespaces per file should be allowed, but strongly
   discouraged as a coding practice of last resort for most users.
4. brackets for namespaces is most necessary for hierarchical
   namespace
   implementations. This is not such an implementation, and as such
   brackets do not add clarity but do slow down the implementation.
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
   b) a clear, uniform coding convention on how to avoid conflicts
   between your code and others that will help those who have to maintain
   the code of others.
   c) a way to alias longer names to increase readability and
   maintainability of code.
6. There are some dangers when using namespaces with autoload, but
   simple ways of thwarting those dangers. Also dangerous is trusting
   external code that is in the same namespace, as functions can be
   redefined.

Detailed answers:

Derick Rethans wrote:

1. As it is impossible to do "use XXX as NativeClass" we get to the

<snip> > extension (DateTime, DateTimeZone). However introducing the new > class > DateTimeSpan might break people's code that do things like: > > &lt;?php > use myNamespace::DateTimeZone as DateTimeZone; > ?>

This is indeed the biggest problem. However, it only exists in the
global "namespace" (non-namespaced code). An example script using the
non-existing hypothetical PEAR2::DateTime class:

<?php
include 'PEAR2/Autoload.php';
use PEAR2::DateTime; // fatal error - use name conflicts with
internal class
$a = new DateTime;
?>

However, the answer is simple and elegant. PHP applications that take
advantage of namespaces should use a namespace in the application
global code that is reserved for application code, like php.

<?php
namespace php;
include 'PEAR2/Autoload.php';
use PEAR2::DateTime;
$a = new DateTime; // $a is an object of class PEAR2::DateTime after
autoloading, or if a previously included file has declared class
DateTime in namespace PEAR
?>

Note that the only difference here is the addition of 1 line of code
at
the top of the file. On the same token, this code:

<?php
namespace php;
$a = new DateTime; // $a is an object of class ::DateTime
?>

works as expected, accessing the internal DateTime class directly.

In other words, 1 line of code is needed to take advantage of
namespace's full protection and ability to import conflicting class
names into the "global" (in this case unqualified, not containing ::
in
the name) scope, while at the same time preserving BC with existing
code
(no modification needed beyond addition of "namespace php;").

I recommend that the manual specify this convention, and will happily
take on the documentation of it.

2. You have to import every class yourself. You can currently not do:

   use myNamespace::* as *; // or similar syntax

Actually, ::* would only be deterministic if use performed some kind
of
autoloading, it's not a question of runtime versus compile-time - it's
simply not possible to determine which class is intended if more than
one ::* is used unless the answer is determined by code loading,
this is
why Java/Python import actually loads code as well as aliasing
identifiers.

There are ways of simulating "use myNamespace::* as *;" that are
almost
as complete and are actually better for long-term maintenance. For
instance, let's say you want to use several classes from
PEAR2::Ultra::Long::Package::Name. You don't need to use each class
individually, you can import the entire namespace:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name;
$a = new Name::ExampleClass;
$b = new Name::SecondThing;
$c = new Name::ThirdThing;
?>

or the ultra-brief method, requiring 3 extra characters over an
unqualified name:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
?>

Even more significant, you can use sub-namespaces with this system,
each
namespace does not need to be imported separately:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass; // $d is an object of class
PEAR2::Ultra::Long::Package::Name::subnamespace::MyClass
?>

This is dramatically easier to debug than the equivalent import of ::*
(with an added namespace for dramatic effect):

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name::;
use Symfony::Something::;
$a = new ExampleClass;
$b = new SecondThing;
$c = new ThirdThing;
$d = new subnamespace::MyClass;
$e = new Controller; // which package is this class from?
?>

Looking at the code, it is impossible to determine which package the
classes come from. Here is the same example with current syntax:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
use Symfony::Something as s;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass;
$e = new s::Controller; // now we know for certain this is from
Symfony
?>

3. We keep bickering over using { } or not, multiple namespaces in a
   file or not... etc. I understand that people want more flexibility,
   but also we need a simple to explain implementation. With the
   current implementation I see the following problems here:

• You can't stick multiple namespaces in one file
• Unlike other constructs in PHP that mark executable blocks,
  namespaces don't use { }.
• The "namespace" keyword at the start of a file is somewhat magic,
  because it can only appear as first element in your script.

I have wrestled with this many times, and the best conclusion I can
reach is that (1) we need the flexibility of multiple namespaces per
file, but that (2) we need to strongly discourage it for the reason
that it is going to make debugging harder. There are two valid use
cases for multiple namespaces per file that I have encountered:

1. performance. PHP is slightly slower when executing stuff in
   multiple
   files
2. GTK2. It's always nice to be able to put a GTK2 app in a single
   file
   and this is an alternative to using a phar archive.

There are two philosophies behind namespaces out there, hierarchical
and
non-hierarchical. In hierarchical languages like C++ and C#, nested
namespaces can be defined, and sub-namespaces can be defined using
nested code blocks. Other implementations simply don't do this. The
best description I've seen is from a site on Perl namespaces:

"Isaac Newton is not related to Olivia Newton-John, and
Newton::Isaac is
not related to Newton::John::Olivia."

Perl, incidentally, uses the package keyword as a combination of
declaration and alias, in that there is no equivalent to PHP's use.

PHP's implementation is a mixture of these approaches. Because it is
closer to Perl's implementation of package, but contains the import
statement from compiled languages like C++, we have to forge a new
path.

Having namespace as the start of the file is good because it
enforces a
declaration "take note: this file uses namespaces" that might
otherwise
be lost.

I have no strong opinion on {}, but I do see a compelling argument in
favor of not using {} for performance reasons if you're only going to
use 1 namespace per file except in extraordinary circumstances.

4. What is wrong with simple prefixes in the first place? Both
   PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for
   different
   'namespaces'. We could optionally create a registry on php.net for
   this to avoid conflicts.

The only naming conflicts we've had have been with internal classes
thus
far, but there is no coding convention in place. Namespaces would
provide a technical solution to a political problem, something that
carries with it intrinsic risks. Fortunately, other languages have
taken this risk before PHP and not had major problems, so we have a
reasonable expectation of success. The implementations of namespacing
vary so widely, it's kind of impossible to generalize on how they do
it,
but difference between prefixing and namespaces can be exemplified by
one construct: use.

<?php
// assume we've loaded code for brevity
$a = Zend_Long_Class_Name::singleton(Zend_Long_Class_Name::CONST);
$b = new PEAR2_Long_Class_Name();
Zend_Long_Class_Name::$var = 2;
?>

<?php
namespace php;
use Zend::Long::Class as a;
use PEAR2::Long::Class as b;
$a = a::Name::singleton(a::Name::CONST);
$b = new b::Name();
a::Name::$var = 2;
?>

Also possible with namespaces is switching out an implementation
with a
similar API without search/replace (assuming no dynamic class
references
are used)

<?php
// before
namespace php;
use Zend::Thing::Implementation;
$a = new Implementation;
?>

<?php
// after
namespace php;
use PEAR2::Does::Same::Thing as Implementation;
$a = new Implementation;
?>

With all the above considerations, especially my first point, I
still have not
heard any good reason why namespaces in the current implementation
are actually
useful - or what particular case they solve... so I am wondering,
are they
really useful? I come now to the conclusion that they are not, and
for myself
(and most likely my work projects) I would have to decide not to go
with
namespaces, but instead stick with the 3 letter prefixing.
Something that I
have totally no problem with, as it is nice and easy.

1. The ability to guarantee short names can be used without danger of
   conflicting with a global name. This is possible inside any namespace
   declaration, but not in global scope.

2. readability, and therefore maintainability increases as redundant
   parts of identifiers are removed by use aliasing. This line:

<?php
return new PEAR2_Pyrus_PackageFile_v2Iterator_File(
new
PEAR2_Pyrus_PackageFile_v2Iterator_FileAttribsFilter(
new
PEAR2_Pyrus_PackageFile_v2Iterator_FileContents(
$this->packageInfo['contents'], 'contents',
$this)),
RecursiveIteratorIterator::LEAVES_ONLY);
?>

becomes:

<?php
use PEAR2::Pyrus::PackageFile::v2Iterator as i2;
use ::RecursiveIteratorIterator as ri; // currently not possible in
CVS
but I have a patch...
// ...

           return new i2::File(
                   new i2::FileAttribsFilter(
                   new i2::FileContents(
                       $this->packageInfo['contents'], 'contents',

$this)),
ri::LEAVES_ONLY);
?>

The argument has been made that namespaces can actually increase code
size because class names are so rarely used. This is not true in my
coding experience. As an example, a single file in PEAR2_Pyrus has 25
uses of the classname PEAR2_Pyrus_PackageFile_Exception. Any class
making use of class constants used by another class will be using the
full classname a lot.

3. Ability to use common short names (like File, Exception, Date) as
   class names within a namespace increases the logical descriptive
   qualities of the code, making it easier to understand without
   documentation (self-documenting code). For example, in the classname
   PEAR2::Pyrus::Config, the only part that really describes anything
   important for the user to know about is "Config", the rest is
   redundant.

In terms of the danger of using namespaced classes with autoload, the
biggest danger is this code:

<?php
namespace Blah;
$a = new Exception('hi');
?>

In this case, the ::Exception class is instantiated.

<?php
namespace Blah;
use Blah::Exception;
$a = new Exception('hi');
?>

Now we guarantee the correct class is loaded. Although this seemed
onerous to me at first, on reflection, there are very few internal
classes that are likely to be overridden by a package (only 98 exist
in
my 5.3 build), probably at most 2 in any given package, so this is
not a
huge burden.

A larger danger is this example:

<?php
namespace foo;
echo strlen('hi');
include 'maliciousfile.php';
echo strlen('hi');
?>

maliciousfile.php:
<?php
namespace foo;
function strlen($a)
{
// do bad stuff
echo "I'm evil"
return ::strlen($a);
}
?>

The above script outputs "2I'm evil2" - foo::strlen() is called for
the
second call to strlen(). Application authors like blogs that run
plugins must be extremely cautious that plugins from third parties
cannot contain redefinitions of core functions inside the blog's
namespace. Of course, any third-party code is dangerous regardless of
language construct, but this is a subtle vector that could be used and
would not be caught by a code scanner unless consciously coded in to
watch for a "namespace foo;" declaration.

I hope this is helpful - by digging deeply into the source and talking
to lots of devs, I have learned a lot about PHP's namespace
implementation in the past 2 days, and I'm certain we have a much
better
implementation than I thought we did 2 days ago, and will be writing
up
a "how to namespace" and "how not to namespace" guide based on the
pitfalls I've discovered in this quest as well as contributing to the
documentation when things settle.

Greg

I agree with everything here, especially the solution to multiple
namespaces per file (allow but discourage), but i don't agree with the
php namespace. If any separation of core php and extensions into
namespaces happens, it should be kept as simple as possible, with root
namespaces like "php::" and "ext::". The application should be allowed
to define its own root namespace, or use a namespace such as "app::".
Besides that I think all of your other suggestions are the best ones.

Hi Derick,

I've been thinking a lot about your provocative email in the past
couple of days, and have come to a different conclusion from my original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). After a few hours of thinking practically about the
implementation, I realized that this would be impossible for the same
reasons as your first argument. So, I set out to find a solution that
keeps namespaces and solves the problems.

I have found the solutions to every problem I could find, and to my
surprise, even after crafting a new patch to solve some of them, have
found a way to solve all of the problems within the existing
implementation (with a few tweaks, but nothing major changed) or by
specifying new coding conventions.

Summary:

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.
2. use Name::*; is technically impossible without some kind of
   autoloading mechanism, but can be reasonably approximated by importing a
   long namespace name as a shorter one. "use PEAR2::Really::Long::Name as
   a;" then allows referring to PEAR2::Really::Long::Name::Classname as
   a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as
   a::Subnamespace::Classname.
3. multiple namespaces per file should be allowed, but strongly
   discouraged as a coding practice of last resort for most users.
4. brackets for namespaces is most necessary for hierarchical namespace
   implementations. This is not such an implementation, and as such
   brackets do not add clarity but do slow down the implementation.
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
   b) a clear, uniform coding convention on how to avoid conflicts
   between your code and others that will help those who have to maintain
   the code of others.
   c) a way to alias longer names to increase readability and
   maintainability of code.
6. There are some dangers when using namespaces with autoload, but
   simple ways of thwarting those dangers. Also dangerous is trusting
   external code that is in the same namespace, as functions can be redefined.

Detailed answers:

Derick Rethans wrote:

1. As it is impossible to do "use XXX as NativeClass" we get to the

<snip> > extension (DateTime, DateTimeZone). However introducing the new class > DateTimeSpan might break people's code that do things like: > > &lt;?php > use myNamespace::DateTimeZone as DateTimeZone; > ?>

This is indeed the biggest problem. However, it only exists in the
global "namespace" (non-namespaced code). An example script using the
non-existing hypothetical PEAR2::DateTime class:

<?php
include 'PEAR2/Autoload.php';
use PEAR2::DateTime; // fatal error - use name conflicts with internal class
$a = new DateTime;
?>

However, the answer is simple and elegant. PHP applications that take
advantage of namespaces should use a namespace in the application
global code that is reserved for application code, like php.

<?php
namespace php;
include 'PEAR2/Autoload.php';
use PEAR2::DateTime;
$a = new DateTime; // $a is an object of class PEAR2::DateTime after
autoloading, or if a previously included file has declared class
DateTime in namespace PEAR
?>

Note that the only difference here is the addition of 1 line of code at
the top of the file. On the same token, this code:

<?php
namespace php;
$a = new DateTime; // $a is an object of class ::DateTime
?>

works as expected, accessing the internal DateTime class directly.

In other words, 1 line of code is needed to take advantage of
namespace's full protection and ability to import conflicting class
names into the "global" (in this case unqualified, not containing :: in
the name) scope, while at the same time preserving BC with existing code
(no modification needed beyond addition of "namespace php;").

I recommend that the manual specify this convention, and will happily
take on the documentation of it.

2. You have to import every class yourself. You can currently not do:

   use myNamespace::* as *; // or similar syntax

Actually, ::* would only be deterministic if use performed some kind of
autoloading, it's not a question of runtime versus compile-time - it's
simply not possible to determine which class is intended if more than
one ::* is used unless the answer is determined by code loading, this is
why Java/Python import actually loads code as well as aliasing identifiers.

There are ways of simulating "use myNamespace::* as *;" that are almost
as complete and are actually better for long-term maintenance. For
instance, let's say you want to use several classes from
PEAR2::Ultra::Long::Package::Name. You don't need to use each class
individually, you can import the entire namespace:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name;
$a = new Name::ExampleClass;
$b = new Name::SecondThing;
$c = new Name::ThirdThing;
?>

or the ultra-brief method, requiring 3 extra characters over an
unqualified name:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
?>

Even more significant, you can use sub-namespaces with this system, each
namespace does not need to be imported separately:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass; // $d is an object of class
PEAR2::Ultra::Long::Package::Name::subnamespace::MyClass
?>

This is dramatically easier to debug than the equivalent import of ::*
(with an added namespace for dramatic effect):

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name::;
use Symfony::Something::;
$a = new ExampleClass;
$b = new SecondThing;
$c = new ThirdThing;
$d = new subnamespace::MyClass;
$e = new Controller; // which package is this class from?
?>

Looking at the code, it is impossible to determine which package the
classes come from. Here is the same example with current syntax:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name as a;
use Symfony::Something as s;
$a = new a::ExampleClass;
$b = new a::SecondThing;
$c = new a::ThirdThing;
$d = new a::subnamespace::MyClass;
$e = new s::Controller; // now we know for certain this is from Symfony
?>

3. We keep bickering over using { } or not, multiple namespaces in a
   file or not... etc. I understand that people want more flexibility,
   but also we need a simple to explain implementation. With the
   current implementation I see the following problems here:

   • You can't stick multiple namespaces in one file
   • Unlike other constructs in PHP that mark executable blocks,
     namespaces don't use { }.
   • The "namespace" keyword at the start of a file is somewhat magic,
     because it can only appear as first element in your script.

I have wrestled with this many times, and the best conclusion I can
reach is that (1) we need the flexibility of multiple namespaces per
file, but that (2) we need to strongly discourage it for the reason
that it is going to make debugging harder. There are two valid use
cases for multiple namespaces per file that I have encountered:

1. performance. PHP is slightly slower when executing stuff in multiple
   files
2. GTK2. It's always nice to be able to put a GTK2 app in a single file
   and this is an alternative to using a phar archive.

There are two philosophies behind namespaces out there, hierarchical and
non-hierarchical. In hierarchical languages like C++ and C#, nested
namespaces can be defined, and sub-namespaces can be defined using
nested code blocks. Other implementations simply don't do this. The
best description I've seen is from a site on Perl namespaces:

"Isaac Newton is not related to Olivia Newton-John, and Newton::Isaac is
not related to Newton::John::Olivia."

Perl, incidentally, uses the package keyword as a combination of
declaration and alias, in that there is no equivalent to PHP's use.

PHP's implementation is a mixture of these approaches. Because it is
closer to Perl's implementation of package, but contains the import
statement from compiled languages like C++, we have to forge a new path.

Having namespace as the start of the file is good because it enforces a
declaration "take note: this file uses namespaces" that might otherwise
be lost.

I have no strong opinion on {}, but I do see a compelling argument in
favor of not using {} for performance reasons if you're only going to
use 1 namespace per file except in extraordinary circumstances.

4. What is wrong with simple prefixes in the first place? Both PEAR_,
   Zend_, ezc*, and ezp* are perfectly acceptable markers for different
   'namespaces'. We could optionally create a registry on php.net for
   this to avoid conflicts.

The only naming conflicts we've had have been with internal classes thus
far, but there is no coding convention in place. Namespaces would
provide a technical solution to a political problem, something that
carries with it intrinsic risks. Fortunately, other languages have
taken this risk before PHP and not had major problems, so we have a
reasonable expectation of success. The implementations of namespacing
vary so widely, it's kind of impossible to generalize on how they do it,
but difference between prefixing and namespaces can be exemplified by
one construct: use.

<?php
// assume we've loaded code for brevity
$a = Zend_Long_Class_Name::singleton(Zend_Long_Class_Name::CONST);
$b = new PEAR2_Long_Class_Name();
Zend_Long_Class_Name::$var = 2;
?>

<?php
namespace php;
use Zend::Long::Class as a;
use PEAR2::Long::Class as b;
$a = a::Name::singleton(a::Name::CONST);
$b = new b::Name();
a::Name::$var = 2;
?>

Also possible with namespaces is switching out an implementation with a
similar API without search/replace (assuming no dynamic class references
are used)

<?php
// before
namespace php;
use Zend::Thing::Implementation;
$a = new Implementation;
?>

<?php
// after
namespace php;
use PEAR2::Does::Same::Thing as Implementation;
$a = new Implementation;
?>

With all the above considerations, especially my first point, I still have not
heard any good reason why namespaces in the current implementation are actually
useful - or what particular case they solve... so I am wondering, are they
really useful? I come now to the conclusion that they are not, and for myself
(and most likely my work projects) I would have to decide not to go with
namespaces, but instead stick with the 3 letter prefixing. Something that I
have totally no problem with, as it is nice and easy.

1. The ability to guarantee short names can be used without danger of
   conflicting with a global name. This is possible inside any namespace
   declaration, but not in global scope.

2. readability, and therefore maintainability increases as redundant
   parts of identifiers are removed by use aliasing. This line:

<?php
return new PEAR2_Pyrus_PackageFile_v2Iterator_File(
new
PEAR2_Pyrus_PackageFile_v2Iterator_FileAttribsFilter(
new PEAR2_Pyrus_PackageFile_v2Iterator_FileContents(
$this->packageInfo['contents'], 'contents',
$this)),
RecursiveIteratorIterator::LEAVES_ONLY);
?>

becomes:

<?php
use PEAR2::Pyrus::PackageFile::v2Iterator as i2;
use ::RecursiveIteratorIterator as ri; // currently not possible in CVS
but I have a patch...
// ...

            return new i2::File(
                    new i2::FileAttribsFilter(
                    new i2::FileContents(
                        $this->packageInfo['contents'], 'contents',

$this)),
ri::LEAVES_ONLY);
?>

The argument has been made that namespaces can actually increase code
size because class names are so rarely used. This is not true in my
coding experience. As an example, a single file in PEAR2_Pyrus has 25
uses of the classname PEAR2_Pyrus_PackageFile_Exception. Any class
making use of class constants used by another class will be using the
full classname a lot.

3. Ability to use common short names (like File, Exception, Date) as
   class names within a namespace increases the logical descriptive
   qualities of the code, making it easier to understand without
   documentation (self-documenting code). For example, in the classname
   PEAR2::Pyrus::Config, the only part that really describes anything
   important for the user to know about is "Config", the rest is redundant.

In terms of the danger of using namespaced classes with autoload, the
biggest danger is this code:

<?php
namespace Blah;
$a = new Exception('hi');
?>

In this case, the ::Exception class is instantiated.

<?php
namespace Blah;
use Blah::Exception;
$a = new Exception('hi');
?>

Now we guarantee the correct class is loaded. Although this seemed
onerous to me at first, on reflection, there are very few internal
classes that are likely to be overridden by a package (only 98 exist in
my 5.3 build), probably at most 2 in any given package, so this is not a
huge burden.

A larger danger is this example:

<?php
namespace foo;
echo strlen('hi');
include 'maliciousfile.php';
echo strlen('hi');
?>

maliciousfile.php:
<?php
namespace foo;
function strlen($a)
{
// do bad stuff
echo "I'm evil"
return ::strlen($a);
}
?>

The above script outputs "2I'm evil2" - foo::strlen() is called for the
second call to strlen(). Application authors like blogs that run
plugins must be extremely cautious that plugins from third parties
cannot contain redefinitions of core functions inside the blog's
namespace. Of course, any third-party code is dangerous regardless of
language construct, but this is a subtle vector that could be used and
would not be caught by a code scanner unless consciously coded in to
watch for a "namespace foo;" declaration.

I hope this is helpful - by digging deeply into the source and talking
to lots of devs, I have learned a lot about PHP's namespace
implementation in the past 2 days, and I'm certain we have a much better
implementation than I thought we did 2 days ago, and will be writing up
a "how to namespace" and "how not to namespace" guide based on the
pitfalls I've discovered in this quest as well as contributing to the
documentation when things settle.

Greg

I've been thinking a lot about your provocative email in the past
couple of days, and have come to a different conclusion from my original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). After a few hours of thinking practically about the
implementation, I realized that this would be impossible for the same
reasons as your first argument. So, I set out to find a solution that
keeps namespaces and solves the problems.

Right, that was the idea behind the mail :) As yours is pretty long, I'm
only going to respond to the main points.

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.

2. use Name::*; is technically impossible without some kind of
   autoloading mechanism, but can be reasonably approximated by importing a
   long namespace name as a shorter one. "use PEAR2::Really::Long::Name as
   a;" then allows referring to PEAR2::Really::Long::Name::Classname as
   a::Classname, and PEAR2::Really::Long::Subnamespace::Classname as
   a::Subnamespace::Classname.

Yeah, I know... I don't really care about this myself anyway - it's just
something that I heard in discussions.

[snip]

Detailed answers:

Derick Rethans wrote:

1. As it is impossible to do "use XXX as NativeClass" we get to the

<snip> > extension (DateTime, DateTimeZone). However introducing the new class > DateTimeSpan might break people's code that do things like: > > &lt;?php > use myNamespace::DateTimeZone as DateTimeZone; > ?>

This is indeed the biggest problem. However, it only exists in the
global "namespace" (non-namespaced code). An example script using the
non-existing hypothetical PEAR2::DateTime class:

<?php
include 'PEAR2/Autoload.php';
use PEAR2::DateTime; // fatal error - use name conflicts with internal class
$a = new DateTime;
?>

However, the answer is simple and elegant. PHP applications that take
advantage of namespaces should use a namespace in the application
global code that is reserved for application code, like php.

<?php
namespace php;
include 'PEAR2/Autoload.php';
use PEAR2::DateTime;
$a = new DateTime; // $a is an object of class PEAR2::DateTime after
autoloading, or if a previously included file has declared class
DateTime in namespace PEAR
?>

Note that the only difference here is the addition of 1 line of code at
the top of the file. On the same token, this code:

<?php
namespace php;
$a = new DateTime; // $a is an object of class ::DateTime
?>

works as expected, accessing the internal DateTime class directly.

In other words, 1 line of code is needed to take advantage of
namespace's full protection and ability to import conflicting class
names into the "global" (in this case unqualified, not containing :: in
the name) scope, while at the same time preserving BC with existing code
(no modification needed beyond addition of "namespace php;").

I recommend that the manual specify this convention, and will happily
take on the documentation of it.

2. You have to import every class yourself. You can currently not do:

   use myNamespace::* as *; // or similar syntax

[snip]

There are ways of simulating "use myNamespace::* as *;" that are almost
as complete and are actually better for long-term maintenance. For
instance, let's say you want to use several classes from
PEAR2::Ultra::Long::Package::Name. You don't need to use each class
individually, you can import the entire namespace:

<?php
namespace php;
use PEAR2::Ultra::Long::Package::Name;
$a = new Name::ExampleClass;
$b = new Name::SecondThing;
$c = new Name::ThirdThing;
?>

Sounds like a good idea.

I have no strong opinion on {}, but I do see a compelling argument in
favor of not using {} for performance reasons if you're only going to
use 1 namespace per file except in extraordinary circumstances.

The only thing that in the case you have a multi-namespace file, using
braces would editors allow to the start and end of a namespace easily
(f.e. VIM's %).

A larger danger is this example:

<?php
namespace foo;
echo strlen('hi');
include 'maliciousfile.php';
echo strlen('hi');
?>

maliciousfile.php:
<?php
namespace foo;
function strlen($a)
{
// do bad stuff
echo "I'm evil"
return ::strlen($a);
}
?>

The above script outputs "2I'm evil2" - foo::strlen() is called for the
second call to strlen().

I thought only constants and classes could be parts of namespaces?

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

Gregory, this is amazing and makes me - and I think many others - feel
confident, that namespacing will make it into PHP6 in a smooth and very
usable way. Thanks for your inteligent work on that.

I'd be pleased in having namespaces like that.

Regards,
Franziskus

Hi Greg,

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.

That answers my main concern, but I'd make it stronger than a
recommendation. I'd make it impossible to import namespaced code into the
global space.

• Steph

Hi Derick,

Now, you cannot override existing classes with "use" statement.
However inside a namespace you don't have internal classes and "use"
works just fine.

<?php
namespace Foo;
use myNamespace::Bar as stdClass;
?>

I think it is clear decision.
If you like to override internal classes just write your code in your
own namespace.

Allowing class overriding is possible from technical point of view (it
is disabled on purpose), but it'll give more mess than advantage.

Thanks. Dmitry.

Derick Rethans wrote:

Hei,

now some patches by Greg and Dmitry made it into CVS, some of the things
in my mail have been resolved, however, we still need to come up with a
solution to the 1st and most important issue:

1. As it is impossible to do "use XXX as NativeClass" we get to the
   point where we'd have to namespace new internal native classes
   otherwise we might introduce BC breaks. AFAIK, we've always said that
   PHP reserves the globals space for it's own use (see also:
   http://www.php.net/manual/en/userlandnaming.rules.php). In case we do
   add new classes (an example could be DateTimeSpan), they should of
   course follow the same format as already existing classes in the
   extension (DateTime, DateTimeZone). However introducing the new class
   DateTimeSpan might break people's code that do things like:

<?php
use myNamespace::DateTimeZone as DateTimeZone;
?>

feature versions of people would then show:

Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument
because the name is already in use.

It would be silly to require to have to do this:

- Create a class PHP::Date::TimeSpan
- In your scripts:
use PHP::Date::TimeSpan

But with the current implementation, this seems to be the only non-BC
breaking solution. If we chose not to require this silly namespacing
of internal classes, users instead have to do this:

<?php
use myNamespace::DateTimeZone as myDateTimeZone;
?>

Basically prefixing the classnames... This you can already do just
fine without namespaces.

I know Greg has some ideas with php as recommendation, but I find it
a bit clumsy still. Perhaps Greg can summarize how it will address the
above issue?

regards,
Derick

Hi again,

I am not sure this will make it through the noise sigh but I'll give a
try :)

Derick Rethans wrote:

Hei,

now some patches by Greg and Dmitry made it into CVS, some of the things
in my mail have been resolved, however, we still need to come up with a
solution to the 1st and most important issue:

1. As it is impossible to do "use XXX as NativeClass" we get to the
   point where we'd have to namespace new internal native classes
   otherwise we might introduce BC breaks. AFAIK, we've always said that
   PHP reserves the globals space for it's own use (see also:
   http://www.php.net/manual/en/userlandnaming.rules.php). In case we do
   add new classes (an example could be DateTimeSpan), they should of
   course follow the same format as already existing classes in the
   extension (DateTime, DateTimeZone). However introducing the new class
   DateTimeSpan might break people's code that do things like:

<?php
use myNamespace::DateTimeZone as DateTimeZone;
?>

feature versions of people would then show:

Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument
because the name is already in use.

It would be silly to require to have to do this:

- Create a class PHP::Date::TimeSpan
- In your scripts:
use PHP::Date::TimeSpan

But with the current implementation, this seems to be the only non-BC
breaking solution. If we chose not to require this silly namespacing
of internal classes, users instead have to do this:

<?php
use myNamespace::DateTimeZone as myDateTimeZone;
?>

Basically prefixing the classnames... This you can already do just
fine without namespaces.

I know Greg has some ideas with php as recommendation, but I find it
a bit clumsy still. Perhaps Greg can summarize how it will address the
above issue?
I've been thinking quite a bit about several suggestions (surprise
surprise). First of all, Marcus Boerger suggested on IRC that "php"
was not the best name, and proposed "user" as a more logical choice
for the convention, which appeals to me more for the obvious reason that
it doesn't have the chance of confusing with "PHP" or "php" should
either of these be adopted by the core folks ever.

I am going to use some shorthand. "internal class is used first" means
this code:

<?php
namespace hithere;
$a = new Exception('hi');
?>

would use ::Exception unles hithere::Exception already exists.

In my inimitable style, for the larger suggestions I've been thinking
about I will list them:

1. having an implicit namespace for unnamespaced code

2. never accessing internal classes inside a namespace (tough to
   summarize I explain below)

3. allowing override of internal classes with "use" in the global scope

4. keep things the way they work now, and recommend using "namespace
   user" for userspace code.

5. having an implicit namespace for unnamespaced code

This is an interesting idea that will break autoloaders unless the
implicit namespace is automatically stripped on a call to autoload,
get_class() and reflection.

Pros:
use myNamespace::DateTimeZone as DateTimeZone; will always work as intended

Cons:
slight performance hit on every autoload caused by a strstr() check on
classname for "auto::" and same hit on get_class(), ReflectionClass
stuff
large number of potential "oops" spots for the implicit namespace to
slip into code and break everything horrendously.
the patch would be huge and very dangerous for the above reason until
kinks are worked out.
doesn't solve the "internal class is used first" issue.

2. never accessing internal classes inside a namespace
   =====================

This basically means changing the autoloading rules to the following
(using the hithere namespace/Exception example from above):

1. does hithere::Exception exist?
2. if not, autoload it

Pros:
it is not necessary to "use hithere::classname" for every class you
might autoload.
1 hash lookup reduced per autoloaded class (very minor performance gain,
hash lookup is O(1). profiling might not even detect a difference.)

Cons:
to use internal classes, you would need to explicitly use ::Classname;
for each of them.
Code that does not use autoload would also have to explicitly use
::Classname;
code that uses internal classes that wishes to become namespaced would
need to go through and figure out which internal classes are used and
add "use ::Classname" at the top of the file, making porting to
namespaces much more difficult.

3. allowing override of internal classes with "use" in the global scope
   =====================

This would be surprisingly easy to implement, currently the only thing
preventing it from happening is a 5-10 line check in zend_do_use() to
see if the name requested would conflict with an internal class. Remove
that check and it becomes possible

Pros:
Derick's main issue goes away, name conflicts with internal classes are
never possible when "use"ing them
it becomes possible to change which class is used in a file with 1 line
of code:

<?php
use myNamespace::Exception as Exception;
?>

As opposed to two:

<?php
namespace user;
use myNamespace::Exception as Exception;
?>

Cons:
It is then possible to accidentally override an internal classname used
in the code.
it encourages continuing to declare classes/functions in the global
namespace, resulting in potential name conflicts a la "Date"

In regards to the braces or no braces question, I have a scenario that I
would like to share that could be considered similar in nature. We use a
cluster of databases where I work, and to make things easier on us, we have
a method called setSource() to switch between the clusters in our database
class. This allows us to easily query between the clusters, but since there
are no braces, we sometimes lose track of which cluster we are working on,
and thus bugs are born. I would think that if it were some how possible to
have braces, it would cause less headaches and problems, because we could
then logically group our queries together. The same argument could be used
with namespaces; especially if the multiple namespace-per-file gets added.
Even without that little bit of functionality, it would make maintaining
namespaced code easier to read at first glance. For small apps, it probably
wouldn't be that big of a difference, but for files that span hundreds (and
even thousands) of lines of code, a developer could easily get lost in in
the namespace they are supposed to be in. Am I in a namespace? Which
namespace? Without the code block, and typical indentation, you could easily
overlook the namespace keyword.

Anyways, I understand that braces are just a bit of icing on the cake -- so
to speak -- but I just wanted to give a probable real-life situation to this
debate. :)

Is there any reason why you can't already use braces optionally? I mean,
the following code is valid with the current engine:

<?php

{
{
{
class Foo
{
function Foo()
{
echo 'Foo'."\n";
}
}
}
}
}

?>

Cheers,
Rob.

...........................................................
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!

...........................................................