Problem/Motivation
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.
Steps to reproduce
Proposed resolution
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 #3506930: Separate hooks from events when hooks no longer use the event system.
Comments
Comment #2
donquixote commentedQuick 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 #3506930: Separate hooks from events.
Comment #3
nicxvan commentedComment #4
nicxvan commentedI'm not sure this status is correct, but I'm not convinced this is the right way to go. There is still some discussion in the impermeable list issue.
Comment #5
nicxvan commentedI think we can close this, the related issue reduces it to a stub only used for targeting with remove and reorder.
It's no longer registered in the container once that lands.
Comment #6
nicxvan commentedClosing this since it's basically a duplicate at this point.