Drupal 8 progress from my / MongoDB perspective: update #19

The biggest changes (at least from my end, as usual) since the last update are allowing plugins to have their services injected. It's perhaps not the most beautiful solution ever but it works. Again for plugins, one directory depth have been removed, it's still ridiculous but less so and the PHP-FIG (nudged by our quicksketch, thanks much) is finally moving ahead with creating a new autoloader standard which will make the directory structure a bit saner.

Now, on to the future: I had a phone call with Dries and a few others discussing the future of hooks. While hooks are familiar to everyone who ever coded for Drupal, they are not object oriented (not unit testable, etc) and so they may (or may not) be off-putting to the new kind of contributors we want to attract. There are many roads we could take: for example, we can convert hooks wholesale (scripted) to a Drupal-specific OOP syntax based on magic naming, attempt the same with EventSubscriber. We feel this should wait until Drupal 9. However, we will add a HookEvent which allows Eventsubscriber classes to react to hooks. Probably we will need to make a more efficient version of the container aware event subscriber, but that's a minor detail. Also, we will attempt, pending it actually passes tests and other gates, most importantly the performance gate to convert all entity hooks into events in core while keeping entity hooks around. This is somewhat both a forward and a backwards compatible solution, reflecting where Drupal 8 stands: on the road from a mostly convention based PHP 4 procedural codebase to a mostly configuration based PHP 5 OOP codebase.

I have spent most of my core time on this entity event patch, it's a big one. It's a very very big one. It not just converts to events it also separates logic out from the storage controllers so that the storage controllers actually deal with storage only. For example, separate the comment thread calculation logic from retrieving the max thread values. Or the user password hashing needs to happen no matter how the user entity actually gets stored. I am getting some help in this, but by far not enough -- so if you are interested in this, please contact me to help, there's not a lot of time left.