Voting starts in March for the Drupal Association Board election.
PSR-4 is now implemented.
See the documentation page for PSR-4 in Drupal 8.
Currently, Drupal 8 is using PSR-0 to organize class files in a directory structure, both for core and for modules.
Some people complain that this results in an unnecessarily deep folder structure, causing a mental and motoric overhead. Others say that this is not a big deal, and not worth doing anything about it.
After a long discussion, it was proposed to use PSR-4 for module-provided classes, instead of PSR-0.
There is a doc page to show how PSR-4 would look like in Drupal.
PSR-4 is officially approved by the PHP Framework Interoperability Group since 16:35, Dec 3, 2013.
It is merged into Composer since Jan 2, 2014.
An implementation for this conversion in Drupal has been developed in and is constantly being rerolled and kept ready. The patch covers all the aspects of this change (class loading, class discovery). It contains a script to make rerolling patches / local changes easier, and it allows for a conversion phase where both PSR-0 and PSR-4 are equally supported, to make life easier for contributed modules.
The move to PSR-4 has been approved/decided two times now (Dries in #111 and #302), but was then put back into "to be debated" status.
A version of Drupal with the conversion already done can be browsed on github.
Arguments pro / con
Learning curve / entrance level
Both PSR-0 and PSR-4 have aspects that could be confusing to a beginner, depending on the background and expectations.
PSR-0 is said to be more logical for people coming from other languages (python, java, ruby), where it is normal to have the full namespace structure reflected in the directory structure within a package.
On the other hand, people on IRC #composer repeatedly ask why they can't abbreviate the two redundant directories. So apparently this is controversial.
Besides, there is the special case for the underscore, which is an additional thing to learn.
The deep directories help to visualize the namespace structure when browsing within a specific module. On the other hand, they also make it take more time to completely explore a directory structure (e.g. when using a web-based repository explorer)
When browsing a complete Drupal installation, the additional subfolder levels might feel redundant and confusing.
PSR-4 lacks the 1:1 match of the directory structure with the full namespace structure. People need to get used to that.
On the other hand, the flat directories make it take less time to explore a project, e.g. with a web-based explorer.
This would be someone who sufficiently understands the directory structure of either PSR-0 or PSR-4, or at least is no longer scared of it, but is not always using the most efficient tools and shortcuts. It could also be an experienced developer who is forced to work with tools that don't provide fancy shortcuts.
Typical activities: Working with a filesystem explorer, clicking around in github or drupalcode.org, using a regular file editor (gedit), using the commandline (but not in the most efficient way), using a file-open dialog, looking at error logs, writing a small custom module with a simple text editor.
Most of the arguments for the supposed DX benefits of PSR-4 apply in this category. The activities above expose the developer to a more verbose directory structure, adding visual clutter, requiring more actions (clicks, page visits, etc), and more mental capacity to remember and work with the more verbose paths.
This would be someone who not only sufficiently understands the directory structure of either PSR-0 or PSR-4, but also makes the most efficient use of the available tools.
Typical activities: Using an IDE with shortcuts. Using the commandline with shortcuts and autocompletion, maybe even custom commands.
It was argued that the impact of the deeper directories with PSR-0 is minimal, if you use the tools efficiently (e.g. tab-tab in the commandline).
On the other hand, the developers behind Composer or the PHP-FIG group who pushed for PSR-4 (and also invented the "target-dir" setting in Composer) seem to hate the deep directories just as much as the "casual" developer.
Composer and the rest of PHP will support PSR-4 asap, so interoperability is not a thing to worry about.
It could even be said that we are better off with PSR-4, since Composer will give this priority in the autoloader.
Cost of the conversion
The main work on the patch is already done. It passes all tests and has been reviewed by a number of people.
However, switching from PSR-0 to PSR-4 also means that pending patches and local branches need to be updated / rerolled.
Conversion of core patches: For every patch, you would
git checkout a version of drupal before the switch to psr-4, as a new (temporary) branch.
git apply the patch, commit to the new branch
git rebase 8.x. This should actually preserve all the local changes to existing files, because git understands if a file has been moved.
php core/scripts/switch-psr4.sh, and commit. This is for files that were added in the patch or local branch.
git diff 8.x to produce a new version of the patch.
- Upload the new patch.
This should work in most cases. But it still means manual intervention for every pending patch in the queue.
Conversion of contrib modules:
Besides, contrib modules that already were ported to D8 need to be ported to PSR-4, including all their pending patches in the queue.
This can be done in a similar way as the core patches above.
The good thing: There will be a conversion phase of e.g. one month or more, where the PSR-0 version of a module will still work. So there is no pressure to port these modules, and it won't suddenly break devel or admin_menu.
Implementation details are in
- Prepare a Drupal release where module-provided classes can live in PSR-0 or PSR-4 likewise.
- Run a script (included in that release) to move the modules to their new PSR-4 location.
- Use this script (and git rebase) to re-roll patches.
- Clean up, and make PSR-4 the only way.
Originally proposed alternatives
Other options proposed in the past can be found in older revisions of the issue summary.