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