Underscore for delimiting version numbers with dots in PSR-1

[Anton Komarev]

It is not valid to use underscore in class names following to the spec: https://www.php-fig.org/psr/psr-1/#3-namespace-and-class-names

I'm creating classes which makes application migrations and versions number are very hard to read because of this convention.

For example migration `from 10.11.2 to 10.11.3` version will look like: From10102To10103

This variant will be much readable: From10_11_2To10_11_3

How to deal with version numbers delimited with dots in class names?

[Asmir Mustafic]

On Thursday, 17 October 2019 18:31:12 UTC+2, Anton Komarev wrote:

For example migration `from 10.11.2 to 10.11.3` version will look like: From10102To10103

This variant will be much readable: From10_11_2To10_11_3

How to deal with version numbers delimited with dots in class names?

Probably this does not answer directly your question, but projects as doctrine migrations allows you to place classes in sub-directories (this namesapces) grouped by year/month. In this way the number of classes in the same folder is really lower.

Asmir

 

[Anton Komarev]

How would it help? Class names should be unique, and uniqueness achievable by adding version numbers to it. Even if we'll move version numbers to directories - it wouldn't do the trick because same issue will appear in namespace.

четверг, 17 октября 2019 г., 19:57:35 UTC+3 пользователь Asmir Mustafic написал:

[Beau Simensen]

Late on this one, but in most of the projects I've seen have migrations in their own directories. If your project is similar, you might consider simply excluding that directory from any automated tools that might be doing checks for style issues. You can either ignore those directories outright, or tweak the rules for to fit your constraints for that directory, like "PSR-1 but [exceptions here]." You'd essentially have two separate checks, then.

This probably isn't required in your case, though, as my understanding of PSR-1 is there is no problem with having underscores in any part of the fully qualified classname. The example in PSR-1 that you linked is showing that you should not use _'s for the purpose of namespacing for PHP 5.3+ code. Code written for PHP 5.2.x doesn't have namespaces so it can only rely on _'s for the purpose of namespacing.

Specifically, the rule for PSR-1 states "Code written for PHP 5.3 and after MUST use formal namespaces" but does not say anything about not including _'s in namespace or class names.

There is some ambiguity between PSR-0 and PSR-4 in how _'s are treated in resolving the final path to the file that contains the code for a given class name, so _'s might be tricky unless you are explicitly using PSR-4. However, a lot of projects (like Laravel, for one) don't actually keep the version / date / number information in the class name itself and relies on something like Composer's classmap autoload functionality.

PSR-4 itself actually includes an example of a class with an _ in the name ( \Acme\Log\Writer\File_Writer ):

https://www.php-fig.org/psr/psr-4/#3-examples

Hope this helps. :)