Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Coming from #548470: Use something other than a single underscore for hook namespacing.
If we introduce a new hook syntax in Drupal 9, we might want to add forward support for this in Drupal 8, in a BC-friendly way.
This will NOT solve any nameclash issues in Drupal 8. It is simply meant for DX and preparation for D9.
There can be other ways to reduce the nameclash potential.
This issue is NOT about discussing the new hook syntax, but how we can add this forward support, independent of how this syntax will look like.
For the sake of moving this forward, we can start assuming that the new syntax will be '__' instead of '_'.
There are good arguments against this. But it is good enough to play around and identify the challenges of trying to support this alongside the old syntax, and while keeping backwards compatibility.
---
The result might be that we don't do anything for D8, and mark this issue as "won't fix". In this case it has still served its purpose, which is, to keep this discussion out of other issues.
Comments
Comment #2
donquixote commentedI already talked with @pwolanin about the possible effect on hook_module_implements_alter().
We think that this is only a minor BC hickup.
The idea is that if the $implementations array contains [$module => $group] (usually [$module => FALSE]), then we look for both $module . '__' . $hook and $module . '_' . $hook.
Comment #3
donquixote commentedA more serious problem is contrib or custom code with a custom version of module_invoke_all() / $moduleHandler->invokeAll().
I would say breaking such code is serious enough to completely give up this plan.
Comment #4
donquixote commentedComment #5
donquixote commentedComment #6
donquixote commentedAnother issue is that checking more than one syntax will slow down hook discovery.
Comment #20
catchNow a duplicate of #3442009: OOP hooks using attributes and event dispatcher!