As I said in my last post we are not yet sure if we need to make some changes to namespaces before we can move from alpha to beta in the current 5.3.0 release cycle. What I did not ask for explicitly is feedback from people that have already started developing code with namespaces. These people are likely the best source of feedback on the current state of namespaces and if the proposed changes to namespaces would be useful or not. As you can see in the thread on internals around this RFC Stas does not feel its necessary, while Marcus still feels its a good idea.
I know that the Doctrine guys are already playing with namespaces and are preparing to move to requiring 5.3.0 in trunk (which will eventually become Doctrine 2.0). Speaking of which, Doctrine has gone 1.0 as planned on September 1st. Very good news in its own right of course.
Anyways, those of you who have dipped their feet in using the current namespace implementation in PHP please let us know what your view point is (even if its just a thumbs up all is well)! Either post a comment here or even better yet post to the internals mailinglist.
I've been working on a couple of projects using namespaces (a project management app, a game building framework and implementation reference; neither particularly huge, but certainly not trivial) and haven't run into any problems, or an instance where I'd need namespaces as block structures.
The only benefit I see is being able to concatenate across namespaces, however I'm not sure I'd ever want to do that, although maybe that is only a consequence of how I'm using namespaces.
That said, I would obviously have to trouble switching to them, it just seems to introduce the potential for additional complexity.
I have been using namespaces on a library I am developing. They have been working well so far, but I haven't done anything extremely fancy yet, so I haven't ran into any problems. I am a little concerned about the autoload problem in the future though.
I found the RFC for namespaces with curly braces to be a little confusing, but I think I got it now except for one thing. If they allow nesting namespaces, what is the expected output of the Nesting tests? Is it:
which is what I would expect?
Another thing I don't like about the proposal is the suggestion of using the alternative syntax. The alternative syntax is for control structures, which I don't think that namespaces are (take classes for example which aren't given the alternative syntax). So I think if we are going to go with the curly syntax, we should make it mandatory. What are the arguments against forcing the curly brace syntax? And if we go with the curly brace syntax, what is the problem with placing code before or after the namespace?
We already ported XJConf to the current namespace implementation and I already updated my book "PHP Design Patterns" (including all code examples) to the current state of PHP 5.3. I had no problems at all with the namespace implementation, but I follow the 'one class per file' rule and we do not merge all classes to one file (well, we kinda do, but include them separately via streams).
So I don't think, that the change would be necessary.
I've been using namespaces since then went into 5.3. From my experience functions in namespaces are basically unusable (you can't alias in a function like you can a class from a namespace - plus there's the ambiguity issue with static methods).
Writing HUGE blocks of use statements at the top is going to turn people off and since included files have their own namespace level you can't even have a file that keeps a block of use statements that are needed on every page.
Since I do more than just web applications with PHP, I HAVE run into the need to get away from the "one namespace per file" rule, and the fact that you can't have ANYTHING before the opening <?php tag in a file with a namespace (no whitespace, no html, nothing) without a fatal error annoys me to no end.
I played around with implementing a package using namespaces a few months ago, and I basically gave up on them because of the autoload problems (http://marc.info/?l=php-internals&m=121527668606247 as already referenced by Schmalls and Elizabeth). I'm not even sure I'm going to move Horde to them, because of the sheer number of use statements that would be required.
I think that user-level classes are far more common in PHP than internal classes, and as such should be given priority.
Tangentially, a killer feature would be having a version of autoload that didn't require a class to be defined as a result. Something like ruby's const_missing, that could autoload a namespaced funtion or a namespaced constant, for example.
So here is a question. If you guys would have a patch to fix things as Greg described. Could at least one of you try and benchmark the performance impact. I am expecting that the number of internals provided OO interfaces will grow rapidly in the future, but the fact of the matter is that most people still prefer to wrap stuff in their own OO interfaces. So maybe Yahoo prefers to keep the old behavior but the bulk of the developers out there might be better of with this change. But a benchmark against some real world code might give a new perspective as to what the performance impact really is.
and change the name resolution rules as described in http://marc.info/?l=php-internals&m=121527668606247
Otherwise there's little point to use namespaces at all. Using pear-like name conventions for userland code would be shorter (of course, within the same namespace the class names would be always short unless they are the same as internal classes)
We switched to namespaces last week for FLOW3 and all related packages. See http://forge.typo3.org/repositories/revision/21/1210 for the needed changes and http://forge.typo3.org/wiki/flow3-overview/Notes_on_using_PHP_namespaces for some notes on the implications.
Currently we don't have any problems with use statements, as we still have fully qualified names almost everywhere, thus autoloading works as expected.
Still, looking into the future I'd love to see an enhancement as proposed by Greg in http://marc.info/?l=php-internals&m=121527668606247 plus some way to get rid of having to use single classes if I could use some wildcard instead.
PS: Posted this to php-internals as well...
The web studio I work in we use namespaces in php 3 years from now, using backported patch...