Conclusion: Postpone to D9
This possible decision to entirely replace hooks is postponed to Drupal 9.
Until then, in Drupal 8, we basically have two systems in parallel (#77 / #78):
- The traditional Drupal hook system.
- Event listeners / subscribers.
These need a better documentation, which is discussed in a follow-up:
The benefit of events/subscribers, besides being slightly more flexible, is that the subscriber classes can have their dependencies injected via DIC.
- Only for special situations: Methods on the bundle class.
The D8 cycle will allow us to gain some experience with event subscribers, and compare them with hooks.
I realize that this will be a little controversial. /me dons flame-proof suit.
We have the Symfony EventDispatcher class in core, and I think we ought to use it as for our hook system. This has the following benefits:
1) Developers coming to Drupal from other systems can immediately understand what's happening (the Observer pattern is pretty common).
2) We could have functions that listen for multiple events.
3) We get rid of the magic function naming thing and replace it with explicitly declared events.
4) We get to leverage external code for something that we're already doing and get rid of a Drupalism in the process.
Patch attached. Adds the drupal_event() function in bootstrap.inc, converts hook_node_presave to the event dispatcher, and changes forum_node_presave to be a listener rather than a hook implementation. It's a fairly minimal changeset - I didn't want to spend a lot of time on it if it was going to be rejected, but I think there's enough there to see what it might look like.
Note: Right now, I'm just considering the event hooks. Alter hooks and declarative hooks are something that I'm not sure how to move forward on. My thought is that most alter hooks could be easily converted to event hooks (ex: instead of hook_form_alter, have form.pre_render or something). We may be able to handle them all the same way. I don't know because I haven't played with it.