Updated: Comment #0
Problem/Motivation
We're going OO but we still have to keep procedural code because hooks can only be implemented by functions.
So what if we could also implement functions in services?
Well auto-magic discovery won't work because of naming conventions so we need a way to nominate what methods implement what hooks, enter module.implements.yml
Proposed resolution
Add a module.implements.yml that allows modules to nominate a service and a method that implements a hook.
Example:
hooks:
node_predelete: 'book.module:nodePreDelete'
Remaining tasks
More test coverage
Caching of parsed implementations - I think CachedModuleHandler handles this already but best confirm
What happens for those rough edges in core where we call foreach ($module_handler->implements($foo, $bar)) instead of using invokeAll?
Check that ModuleHandler::implements work too.
Data returned from ModuleHandler::getImplementations is no good, as it only returns the keys we need it to return the same as ::getImplementationInfo.
User interface changes
None
API changes
Well ModuleHandler::implements() && function_exists($module . '_' . $hook)
is no longer enough because we're also storing data in the implementations, not just the group. In these cases the data returned from ModuleHandler::getImplementations is no good, as it only returns the keys.
Related Issues
Comment | File | Size | Author |
---|---|---|---|
services-implement-hooks.patch | 9.01 KB | larowlan | |
Comments
Comment #1
Crell CreditAttribution: Crell commentedThis doesn't seem useful to me. If we want to support OO-based hooks, those are called events. The linked issue is already starting in that direction, since that's where we want to go long term. I don't know if we can get the other issue in at this point, but I definitely prefer that approach to further developing hooks as-is.
Comment #2
larowlanI guess the main difference between that approach and this one is the old module_implements_alter trick can still be used to alter order, resolving the main issue there which was where do events come in the timing.
I agree events are the way to go for Drupal 9, so maybe this is a compromise for Drupal 8?
Either way it was more of a 'scratch an itch' thing so I'm not really fussed, although I do like the idea of a module with no procedural code :)
Comment #3
dawehnerLinking the issue which allows you to register events based on yml files: #2023613: Move event registration from services.yml to events.yml
Comment #4
Crell CreditAttribution: Crell commentedLet's close this in favor of #1972304: Add a HookEvent and friends.
Comment #5
larowlan