Lowercase or CamelCase namespaces?

PascalCase it is, then :wink:

3 Likes

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.

2 Likes

Yeah, thanks :slight_smile:

1 Like

I remember it by thinking that the camel really is a dromedary in disguise, and that the real camel goes by the name ‘Pascal’ :slight_smile:

(Dromedary = one hump, camel = two humps)

2 Likes

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 :stuck_out_tongue:
I guess too much C programming. But also because it’s just too convenient to type.
Mostly for local and member variables, though. :wink:
I am totally fine with PascalCase, however.

2 Likes

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.

1 Like

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.

1 Like

It looks like decision has been made. Is there any official announcement (preferably with some reasoning - this is big change, especially in BC context)?

1 Like

@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. :stuck_out_tongue:

2 Likes

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.

These are only examples. They’re not even recommendations - standard does not say anything about case of namespaces.

I said they are examples and I didnt say they are recommendations. But to me, the point is that, for some reason, they preffer to use StudlyCaps and they show that in all namespaces of all PSRs. Is not that the place where php devs are looking for examples and recommendations of standards? I think so.

This is example of consistency. Treating this as an recommendation is just overinterpretation.

I am wondering why not consistency examples in lowercase or camelCase. Other vendors probably looked at those consistency examples and realized that all they need is exactly “consistency”, even although it was not a recommendation (till now).

Furthermore, if PHP-FIG would decide to make a recommendation about this in some moment, it is easy to see what would be the more consistent choice they would pick.

Here’s preliminary decision:

Not set in stone yet.

4 Likes