[policy, no patch] Encourage hooks over event subscribers

I do prefer using events in many situations for the exact same reason other people dislike them: Introducing an event requires introducing a custom value object class. Introducing a hook doesn't.

For code authors, the event class is a good place to document requirements and expectations for an extension point. I know there is mymodule.api.php but in my personal experience, I cannot be trusted to keep that up-to-date. Even more so because I do not have any tooling for my IDE to display hook documentation where it would be most useful (i.e. when I implement hooks). With the event pattern, the docs are available where the event is used.

I think the event value object class having its own distinct type reduces accidents due to type confusion and it simplifies static code analysis. But I guess that hook implementations could be just as safe with a set of phpstan rules examining hook implementation parameters.

For code users, the event class is handy to quickly navigate to places where an event is dispatched or where it is handled. Sure, I can grep for Implements hook_XYZ (or nowadays #Hook('XYZ')) and just hope that I find every implementation. But I do enjoy the fact that my IDE is able to quickly list every usage of an event class with built-in tooling. No magic needed at all.

My gut feeling is that hooks have their strengths when operating on loosely typed stuff (e.g., form structures, render arrays, processing of twig variables, etc.). On the other hand, events are best used in conjunction with clearly defined types (e.g., UserFloodEvent operating on a user entity in core or the commerce_order.order.paid event operating on an order in commerce).

I see where you're going with #2 but there is no reason that I know that a Hook can't use a value object too, right? Some already get entity objects (e.g entity_insert) so you could do the exact same thing that you do with an event?

The plan is to introduce subclasses of Hook and move the doxygen from api.php there. There are nuances around dynamic hooks, that discussion is at 📌 [PP-1] Determine how to implement Form Alters with attributes. Active .

I wouldn't say hook implementations can replace event dispatcher altogether.

I can add a listener to the event dispatcher dynamically on runtime.

$anon = new class {
  public function userCancel(): void {
  }
};
$eventDispatcher->addListener(UserCancelEvent::class, [$anon, 'userCancel']);

When the event is dispatched, the anonymous class's method is called. However, the same thing does not work with hook implementations.

$eventDispatcher->addListener('drupal_hook.user_cancel', [$anon, 'userCancel']);

I'm not sure if this is a bug or if this is intended, but at the very least there is a feature missing if we want to replace event dispatcher.

Please file a feature request for that; it needs to go on ModuleHandler and not the event dispatcher.