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.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

donquixote created an issue. See original summary.

donquixote’s picture

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 #3506930: Separate hooks from events.

nicxvan’s picture

Component: base system » extension system
nicxvan’s picture

Status: Active » Postponed (maintainer needs more info)
Related issues: +#3519561: Introduce ImplementationList objects per hook, to simplify ModuleHandler

I'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.

nicxvan’s picture

I 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.

nicxvan’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)
Related issues: +#3516146: Rethink hook ordering attributes targeting procedural hooks without "ProceduralCall" class reference

Closing this since it's basically a duplicate at this point.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.