this looks weird.
Again, just do what most big package providers do, use CamelCase
You don’t have to love it, you just have to accept it, most people are used to it, so you’ll make life easier for lots of people and an even easier transition between frameworks at work, where people might work with 2 or 3 frameworks.
Pick your battles, this isn’t really one of them.
@twisted1919
Be nice, constructive & not offensive.
The way you express yourself contributes also to framework’s culture.
There are enough arguments for all 3 variants.
I provided mine. So did you.
ah, sorry if that came as offensive, that wasn’t my intention, i’ll edit my comment to sound better.
If there is an adoption by majority of nowadays packages, why not go to the majority to simplify?
What is better for anyone who read and write code: to have a ‘standard’ expectation or have to adapt to many styles? I personally prefer PascalCase not because it is beautiful or what, but because it is more understandable when you have to use similar names in code for classes, methods or any other things that have to be distinguished.
‘Such As’ may be named SuchAS, if not may be confused to ‘Su Chas’ or ‘Suc Has’ or even ‘Suchas’.
naming can be anything but must be clarified, and PascalCase does it very well. I think camelCase does it also but not so well as PascalCase.
Personally I prefer “camelCase” or “lowercase” for namespaces, but almost all packages use PascalCase for namespaces now. Having parts lowercase and PascalCase together in a project leads to confusion because people need to remember the case additionally to the name.
So, despite I like camelCase more I would vote - with a for PascalCase as it’s much more widespread and it may feel more familar for people coming from other frameworks. And integrated 3rd party components also do not that alian.
But there is also a good reason to stick with camelCase: Changing everything would make migration difficult.
@twisted1919 is right. We should follow trends. Otherwise we will get out of the main stream. I vote for CamelCase.
PascalCase it is, then 
That’s a bit confusing. Camel Case usually means “starting with lower character and use upper in the middle”: “camelCase”.
Starting with upper is usually called PascalCase as this has been the standard in Pascal language for quite a long time. An alternative name is “Upper Camel Case”.
But when just Camel Case is used as term, most people think about starting with lower.
Anyway: Despite I personally like camelCase more and changing everything to PascalCase might cause quite some migration trouble I vote for PascalCase for namespaces as it’s wide spread and most people are used to it.
Yeah, thanks 
I remember it by thinking that the camel really is a dromedary in disguise, and that the real camel goes by the name ‘Pascal’
(Dromedary = one hump, camel = two humps)
I would vote for Pascal case if this problem received a reasonable solution
Yii\Db\QueryBuilder as class vs Yii\Db\QueryBuilder as namespace as in Yii\Db\QueryBuilder\SimpleBuilder
I vote for PascalCase or camelCase, just because it makes namespace more readable.
And in my personal view, I prefer to PascalCase instead of camelCase since most of packages use PascalCase, makes code more pretty.
I am probably the odd one out, because I actually prefer to use snake_case in my own coding 
I guess too much C programming. But also because it’s just too convenient to type.
Mostly for local and member variables, though.
I am totally fine with PascalCase, however.
While I still find camelCase more logical, I’d also be fine with PascalCase, but only because like every other PHP project I know uses it.
This might be a “marketing” decision, but Yii 3.x might “look better” (or more compatible with the existing PHP-ecosystem) to newcomers with PascalCase.
Usually I do not vote the same as the majority just for the sake of it, but in this case - well, it’s a bit like the discussion between spaces and tabs… and nowadays your IDE should do the namespacing for your anyway.
I agree.
I can be quite stubborn when it comes to conventions and design approaches I consider useless. “Everbody does it” is not an argument by itself. But: Following a standard or (defacto) standard has some value. Esp. for frameworks and libraries.
Personally to me the major reason why I gernally prefere camelCase over PascalCase in namespaces is that I do not like uppercase directory names. They look strange to me.
But esp. as Yii 3 aims to be more open to libraries not really depending on Yii it makes IMO sense to follow the trend as Users do not think so much about “Oh… here I am in the Yii-sphere so it’s lowercase” and “Oh, here I am outside the Yii-Sphere so it’s probably Uppercase”.
So despite i personally would prefer camelCase I see the value of following the trend in order to make Yii not look “foreign” and support PascalCase.
It looks like decision has been made. Is there any official announcement (preferably with some reasoning - this is big change, especially in BC context)?
@rob006 I think that the poll results were used to make the decision.
I started to apply it on mutex & log yesterday, but to be honest, I don’t really like it and I would have settled for camelCase instead.
Let’s see if your proposed changes for the root namespace makes it, and then reconsider this.
I don’t think that the pool is enough. First, democracy is not the best way to make architectural decisions, and I didn’t see any valid argument in favor of PascalCase (except “everyone uses it, so let’s be like everyone”). And second, the pool is tendentious and misleading, since this is not a choice between CamelCase and lowercase, but between camelCase and PascalCase.
Technically, since camel case wins the pool, we should stick to what was used so far.
this is big change, especially in BC context
If the other structural changes had been minor for Yii3 I would have also gone crazy if name-space renaming had been the only real breaking change causing a lot of work.
But as it’s obviously not possible to maintain a extension supporting both - yii3 and yii2 - anyway, I do not mind that much and see at least the advantage of following the trend (esp. as some Yii3 stuff aims to be independend of the “Yii Application framework”). When people start using some of the libraries independend of full yii applications it can also be a indirect advertising for Yii:
A bit like “Oh, their BaseObjects and helpers are cool - may be I should have a look at the whole thing”
I think it is not only about “to follow the multitude” since all examples we can see in https://www.php-fig.org/ are using StudlyCaps. I personally preffer lowercase or at least camelCase, but, after to check php-fig and considering their importance about “standards” in PHP world, I am for StudlyCaps.