The ProceduralCall class is an artificial construct to allow procedural hook implementations to be in the same list as oop implementations. They also take care of include files for procedural implementations.
One strange thing here is that we have arrays [new ProceduralCall(...), $function] in a list of callables, when $function is not at all a method on the ProceduralCall object.
Another problem is we have to analyse the callables in ModuleHandler, and distinguish if the object is a ProceduralCall.
Drop the ProceduralCall class.
Have the list contain a single string with the function name.
For include files just have a general list of files per hook.
Check if this works with EventDispatcher, otherwise postpone this after
🐛
HookCollectorPass registers event listeners but they do not follow the required calling convention
Active
when hooks no longer use the event system.
Active
11.0 🔥
base system
Quick observation from my experiments:
We register the hooks as event listeners using service tags.
This is why it is not straightforward to register a function, even though symfony EventDispatcher by itself does allow that.
This means we better postpone this change until after 🐛 HookCollectorPass registers event listeners but they do not follow the required calling convention Active .