Deprecating PSR-0 in favor of PSR-4 #714
Conversation
|
Not getting a lot of love from one of the stacks ... |
|
Sorry, but there is no added value in this pull. The PSR-4 is meant to simplify directory structure. And you haven't simplified the directory structure. |
|
There is no requirement to change the directory structure for moving to PSR-4, that's totally optional. The code tree isn't that complex worth the effort. PSR-0 is now officially deprecated and all major projects are shifting away from it so I do not see for which reason Elastica shouldn't jump on the band wagon as there is no harm. There might be no direct added value for the library itself (apart from moving the test folder up a bit) - we should encourage adopting the PSR-4 standard unless there is a legit reason not to. Also take a look at this topic composer/composer#1884 (comment) regarding priority in Composer's autoloading (although it doesn't apply when using full classmap). |
|
@skymeyer I'm happy to have PSR-4 as a first step in place. As I'm not too familar with PSR-4 yet: Could there be any issues with projects that are still using PSR-0? |
|
@skymeyer I know it's optional, but the whole point of PSR-4 is to have simpler directory structure. This is just PSR-0 masked as PSR-4 => no added value. Please note, that I'm not saying this pull is bad, I support the adoption of PSR-4, but let's call things with their real names. I'm just saying, that this is not enough and should go further => simplified directory structure. @ruflin not if they're using composer. |
Deprecating PSR-0 in favor of PSR-4
|
I merged the pull request and opened an issue here for further migration to PSR-4: #715 |
As of 2014-10-21 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative (http://www.php-fig.org/psr/psr-0)