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.

#1972304: Add a HookEvent

CommentFileSizeAuthor
services-implement-hooks.patch9.01 KBlarowlan
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Crell’s picture

This 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.

larowlan’s picture

I 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 :)

dawehner’s picture

Linking the issue which allows you to register events based on yml files: #2023613: Move event registration from services.yml to events.yml

Crell’s picture

Status: Needs review » Closed (duplicate)

Let's close this in favor of #1972304: Add a HookEvent and friends.

larowlan’s picture

Title: Allow services to implement hooks by nominating methods in a module.implements.yml » Allow modules to implement hooks by nominating methods in a module.implements.yml

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.