On Monday 30 March 2026 20:37:28 (+02:00), Larry Garfield wrote:
> 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?
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
