On Mon, Mar 30, 2026, at 6:21 AM, Rowan Tommins [IMSoP] wrote:
> On 30 March 2026 10:51:22 BST, Hans Krentel <[email protected]> wrote:
>>
>>When you spotted those, were they also with such a generic invocable
>>interface as in this idea in their interface hierarchy?
>
> If they had any interfaces at all, I would expect them to be specific
> to the use case. As I said earlier, I can't see how you would use an
> interface that asserted just the existence of the method without any of
> its signature.
>
> Regards,
>
> Rowan Tommins
> [IMSoP]
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?
--Larry Garfield
