Deprecate hook_hook_info()

lazy-loading legacy hook implementation code

Please have a look at views_hook_info().

None of that is legacy. Until something like #1972304: Add a HookEvent or #2043653: Allow modules to implement hooks by nominating methods in a module.implements.yml goes in, I don't see how or why we should move forward here.

#1443308-97: Add static cache to module_load_include() shows that views_hook_info() is a net negative for performance. With an opcode cache, having the hook implementations in the module file has a negligible impact, vs. the discovery which is non-negligible.

Also we can't nuke this until 9.x unfortunately, but we can discourage it before then.

I like the idea of killing it, although it would be nice for some of the code organization benefits that it provides to be retained (and in fact expanded).

But I guess that can still be done with require_once statements at the top of the .module file...

Should we issue a deprecation notice?

deprecated in Drupal 8.0.x, will be removed in Drupal 9.0.x

@dpi That sounds good but 8.3.x or 8.4.x would be the start were it was deprecated.

We're trying to figure out how to @trigger_error() for deprecated hooks here: #2870058: [policy, no patch] Document how to deprecate hooks

Policy accepted https://www.drupal.org/core/deprecation#how-hook
Still no replacement for the hook

I don't understand why this is being suggested.

If we replace hooks completely, fine. But we are not there yet I think.
Until then, something like hook_hook_info() is useful for code organization, similar to autoloading for classes (not autoloading itself, but the PSR-4 file organization that is made necessary by autoloading).

views_hook_info() is a net negative for performance. With an opcode cache, having the hook implementations in the module file has a negligible impact, vs. the discovery which is non-negligible.

To me, performance is not the main reason for not putting everything into the main *.module file.

I like the idea of killing it, although it would be nice for some of the code organization benefits that it provides to be retained (and in fact expanded).

Yes. Code organization +1.

But I guess that can still be done with require_once statements at the top of the .module file...

Yes, but:

• no longer forces a convention. Instead, you can now put your hook implementations into whichever file you want. Conventions are good. Forced conventions are good.
• requires explicit require_once statements, whereas with a hook_hook_info() you can simply create the file with the hook implementation. Such lists of require_once are a typical source of merge conflicts - easily resolved, but still annoying.

The issue summary contains some more arguments, which are quite old.
I don't know if these are still valid.

As long as we have hooks, it would be useful to be able to force a convention for file organization per hook.
I am not married to hook_hook_info() specifically, but we should find more convincing reasons to remove it, and/or suggest a good replacement.

Removed field_hook_info() from IS as it was moved to views_hook_info() in #2399931: Generic entity api field handler should live in views module not in field module

So only tokens and views using this hook but it needs to deprecate \Drupal\Core\Extension\ModuleHandlerInterface::getHookInfo() as well

Filed follow-up to remove broken ref #3346614: Remove stray reference to field_hook_info()

Closed as duplicates

- #1373884: [meta] Core does not use hook_hook_info()
- #1107528: Stop using magic functions and force modules to declare the hooks they want to implement
- #1029158: Let hook_hook_info() handle hooks in .install files (aka "rename MODULE.install to MODULE.install.inc")

If we replace hooks completely, fine. But we are not there yet I think.
Until then, something like hook_hook_info() is useful for code organization, similar to autoloading for classes (not autoloading itself, but the PSR-4 file organization that is made necessary by autoloading).

Just to answer #19 - a lot of modules and some of core too already puts the logic of their hook implementations into classes, so that the hook implementation in .module is just three lines or so. This pattern is available for every hook, not just the ones that have hook_hook_info() implemented for them.