Personally I prefer lower case or the camelCase (not PascalCase). But there is an ugly but important point I want to raise is the ease of adopting for new comers. Laravel took a lot of the focuses these years and they used PascalCase. If Yii use PascalCase and when people are sick of Laravel or they simply just want to explore what’s available then Yii will have the edge over those not using because these people will find Yii more familiar.
I know people don’t switch over just because of namespace naming convention and I quite hate to say one framework has to live under the shadow of another framework but small things like this will build up to it’s ‘friendliness’ to the users.
In the end it is namespace we are talking about. It should be relatively easy just to refactor the namespace path during an upgrade and people are expecting changes from Yii 2 to Yii 3 anyway.
As comments @cebe these aspects are the decision of the team of developers, who must clearly define the Core Framework Code Style before continuing with the development and thus be able to follow the recommended guideline.
I always felt Yii is a bit retarded related to the lowercase aspect of namespacing, never understood why it went with it in the first place, but hey, we adapt…
This is visible especially when you are using lots of 3rd-party libraries, i.e:
<?php declare(strict_types=1);
namespace extensions\storagemanager\common\models;
use Aws\S3\S3Client;
use League\Flysystem\AwsS3v3\AwsS3Adapter;
use League\Flysystem\Filesystem;
use yii\helpers\ArrayHelper;
Which looks weird, as opposed to:
<?php declare(strict_types=1);
namespace Extensions\StorageManager\Common\Models;
use Aws\S3\S3Client;
use League\Flysystem\AwsS3v3\AwsS3Adapter;
use League\Flysystem\Filesystem;
use Yii\Helpers\ArrayHelper;
Which clearly looks much better and compatible with the other libraries definitions.
I’ll vote for changing into camel case, or whatever most of PHP libraries are using now. See php league, laravel, symfony, cake, etc, and follow that, we really don’t have to be different here.
I used to understand if smthng is a class by looking for a backslash after its name. IMHO
Yes, thnx
If we can choose between three variants, I’d prefer camelCase. PascalCase is on the second place for me.
There is no any logical reason, just I see camelCase a bit prettier.
PascalCase looks nice and all, but I’m not a fan of it for namespaces. Using camelCase for the namespace seems more fitting.
If major packages died, should Yii die? LOL!
Ultimately it’s whatever. As long as we can import and clearly read what’s being imported then I don’t care as much.
I also prefer lowercase namespaces. I remember when I used Guzzle for the first time. They provide a number of helper functions in the ǹamespace GuzzleHttp\Promise. A typical usage in PHP looks like this:
<?php
use GuzzleHttp\Promise;
// [...] Some code
Promise\unwrap($promises);
// [...] more code
When I first worked with Guzzle, I remember having a hard time to understand how the above code works since I always assumed that Promise is a class as opposed to a namespace. In Yii we wrap helper functions as static methods of a class — so that problem wont arise. But I think thats definitely a reason against PascalCase for namespaces (like @schmunk already wrote)
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.
@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.
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.
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.
