# RFC proposal: Invokable interface

- Thread: https://externals.io/message/130521
- Original archive: https://news-web.php.net/php.internals/130521
- Started by Hans Krentel on 2026-03-31T14:04:03+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #130521 — Hans Krentel — 2026-03-31T14:04:03+00:00

URL: https://externals.io/message/130521#130521

> 
> > […]
> 
> This has sort of come up in designing the compose operator that I've been working on, on-and-off.  I'd want to allow Closure + Closure to return a closure, but also allow Invokable + Closure, Closure + Invokable, and Invokable + Invokable to return a closure.  But right now there is no obvious way (to me at least) to detect an Invokable object and treat it accordingly.  So that's where it might be useful to me, at least.
> 
> However, that's an engine level check, not one that would make sense in user-space.  In user space, I'm not entirely sure where you would want this and not *also* want a use-case-specific interface.
> 
> I've done quite a bit of dynamic dispatch work lately, and `is_callable()` and method_exists('__invoke') have sufficed for what I need.
> 
> As an older example:
> 
> https://github.com/php-fig/event-dispatcher-util/blob/master/src/ParameterDeriverTrait.php
> 
> I'm sure someone will argue it could be simplified with more modern assumptions, but for the sake of this thread, how would an Invokable interface make that code cleaner?

Since you wrote that "is_callable() and method_exists('__invoke') [abbreviated in the original] have sufficed", I imagine that is_invocable() is clearer than `method_exists()`, and since there would be an interface for it: $x instanceof Interface.

But that’s perhaps just my opinion, because for structural and implementation inheritance, I’ve also found that method_exists(...) is practical, and as is so often the case in PHP script code, there’s a certain tendency that steers the code in that direction, and that can be fine; nevertheless, I would say that I personally would still prefer interface inheritance, so the minimal addition I could imagine ad hoc would be an extension of that, similar to what you wrote, to also have an application-specific interface. If I’m not mistaken, this cannot yet be declared as an extension with non-optional method parameters, but that doesn’t answer the previously raised questions about whether this is necessary for PHP scripting scenarios. However, this is merely a preference for interface inheritance; the advantage of structural and implementation-based inheritance remains, since the interface is automatically assigned. Therefore, I would conclude that some detail-oriented developers might gain even more clarity from this. It is really difficult to argue about things we cannot yet see, and contracts only provide as much as the concrete contract can guarantee.

Given the event is the interface, it certainly is invocable.

-- hakre