That guide doesn’t actually dictate how namespaces are named, just that ‘Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lower case and upper case’. 
It does dictate how class names and class constants should be named. Namespaces should just follow psr-0.
Thanks for the link, btw.
Looks like a great guide.
PSR-0 is a good one. PSR-1 and PSR-2 are good as well but only as a base for your own standard since these are very subjective.
While we are looking at standards:
I assume Yii will have a built in logging functionality. Will it follow PSR-3 or wil it have its own interface?
If yii follows psr-3 and uses composer I hope that we will get the "real" interface aviable:
Its own.
Any reason for this? Anything you plan to implement that couldn’t be done following the PSR? Or is there anything you don’t like about it?
To me, it looks very similar to the current CLogger (looking only at the interface).
the log level specific helpers are missing in CLogger
they define other log levels
the context array is missing in CLogger, but shouldn’t be hard to implement. The interpolation it provides seems handy, I often find myself writing log messages like “Something happened, reason was: ‘{$reason}’.”
the category is missing in the PSR. Not sure how this can be solved, maybe by using several logger instances (one per category).
The category is the main showstopper here.
Did you already decide how to access the logger functionality? Will it remain a static helper, or will there be instances? A quick search yesterday showed, that both log4php and monolog support a concept similar to categories (not sure if they can be nested though) and support or plan to support PSR-3.
Even if you don’t plan to use PSR-3 interfaces directly, it might be worth using an abstract logger class or an interface, so one can easily implement an adapter to a PSR-3 compatible logging framework.
The design of the logger is already finalized and implemented. We will not follow PSR-3.
Our logger is not a static helper (similar as in Yii 1.1). It just happens that the logger interface is exposed via Yii like static methods.
Sure, sorry for that inaccuracy. 
In fact, I very much like the way yii allows us to configure log routes, filters and stuff. Not sure if I would switch to another logging framework even if I could. Also, it’s hard to argue without knowing what you’re coding.
And after reviewing how the logging currently works, I think it would be even possible to inject a 3rdParty logging framework in Yii 1.1. It’s basically the LogRouter that needed to be exchanged with an adapter.
Thank you for understanding. If you have specific improvement suggestions, please let us know.
Hi Qiang and Alex,
I’ve read through this thread and found that the OP’s question is not really answered.
As PSR-0 does not dictate to use uppercase first letters for namespaces, but virtually every PHP project with namespaces - I’ve looked so far - uses UpperCase\FirstLetters, I really would like to know if \Yii will adopt this format also?
I would also suggest it, because it’s like an unwritten convention now.
Best regards,
\Schmunk
I’m actually debating about both choices. If we choose to use CamelCase, how should we name the Yii static class? We would like it to be \Yii, which would confuse users with the \Yii namespace.
If I get it right like, you’d have something like:
echo \Yii:t()
$obj = new \Yii\Base\Object();
Why would it confuse users? I would say the syntax prevents misuse.
I’d actually like it
How do others deal with it?
I mean the options aren’t that much, it would have to be either \YII or \yii if not the above.
Another problem would be that the naming of directories will be mixed.
For example, for models directory, you would need to name it as "Models" so that your model classes could be namespaced as "\My\Models\Post".
However, for other directories not storing PHP classes, you don’t want to do so in general.
Here’s my fifty-cents:
Usually namespaces follow the same naming conventions as the folder structure. I don’t know what you’ve have planned for the folder naming conventions in yii2 but I think that it would be great if it followed the same naming conventions as it’s predecessor. In other words it would be something like:
echo \Yii::t();
$obj = new \yii\base\Object();
Many projects use a /src folder now to store their PHP classes, usually the autoloader maps this directory.
I think your example applies for the application directory (currently “protected”), “public” files are separated anyway and don’t have to follow these conventions.
At the moment I can think i.e. example of uploaded data and non-PHP scripts which go also into “protected”, but maybe it’s time to refactor the protected structure.
I know that the existing one is a very slim implementation and very useful for running your app out-of-the-box from your default webserver root, but I won’t sacrifice so much for it.
@schmunk: This has nothing to do with "protected" or "src".
How would you name your view files and view directories? And what about data directories, etc.?
@Chris83: The current implementation of Yii 2 uses the namespace format like you wrote (same as Yii 1.1). Here we are debating whether we should adopt CamelCase in namespace in Yii 2. So far, I’m most concerned with the mixed use of cases in directory names: class directories use CamelCase, while non-class directories use lower-case, which doesn’t look good to me.
Haven’t tried, looks weird and just for the sake of completion (not as a proposal):
\_Yii
But may work according to PSR-0
You can name them any way you want, since they don’t contain classes.
Personally I don’t see the mixture as a very crucial point, because it would also indicate a different usage of the contained files.