Add object oriented hook implementations

[rodrigoaguilera]

Drupal >11.1.0 has support for hook implementations in classes with attributes.
https://www.drupal.org/node/3442349

And it seems that many core hooks are moving to this kind of implementation.

Is there any interest in implementing this early to generate code?

[andypost]

Sounds like good idea

[Chi-teck]

I propose generating single hook classes like following.

#[Hook('help')]
final readonly class Help {

  /**
   * Implements hook_help().
   */
  public function __invoke(): void {
  
  }

}

[weitzman]

Nice ... I propose omitting the Implements hook_help(). doxygen. I know that core kept it so far but thats because they couldn't quickly agree on how to deal with api module integration. This isn't a concern for custom drupal code. I think Drupal core will eventually get rid of this duplicative code comment.

[Chi-teck]

The relevant core issue
https://www.drupal.org/project/drupal/issues/3493453

[PierrePaul]

Some static code analysis tools might whine a bit about a function with no doc comment though.

[nlighteneddesign]

Happy to see this being worked on

I like the single class, but for a lot of hooks it makes sense to group them, I think that would massively complicate this feature though and it's pretty easy to reorganize, so a single hook class with __invoke probably makes the most sense.

Not a fan of final on everything that gets generated, it just complicates things.

Also probably overkill here, but extended hook classes for things like #[FormAlter('form_id')] are likely coming soon too:
https://www.drupal.org/project/drupal/issues/3479141

[weitzman]

Some static code analysis tools might whine a bit about a function with no doc comment though.

Thats a problem with the config of those analyzers. IMO should not add useless comments to satisfy the bots.

[Chi-teck]

To clarify the issue is not about static analyzers but code sniffers, namely drupal coder. There are a few issues on drupal.org about removing redundant dockblocks.

[acbramley]

FYI the organisation/naming/grouping strategy for Hook classes is being discussed here https://www.drupal.org/project/drupal/issues/3493453

IMO if drush is generating 1 class per hook that's fine, but I would lean heavily on the side of wanting a module name prefix in the class. Having 20 classes called "Help.php" is going to make for tiresome DX.