Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130521
Content-Type: text/plain; charset=utf-8
Message-ID: <1774965818283.1983519908.748210733@yahoo.de>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC proposal: Invokable interface
Date: Tue, 31 Mar 2026 14:04:03 +0000
User-Agent: Vivaldi Mail/7.9.3970.45
Content-Transfer-Encoding: quoted-printable
Precedence: list
MIME-Version: 1.0
References: <1774965818283.1983519908.748210733.ref@yahoo.de>
From: hanskrentel@yahoo.de (Hans Krentel)





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 <hanskrentel@yahoo.de> =
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=20
> > to the use case. As I said earlier, I can't see how you would use =
an=20
> > interface that asserted just the existence of the method without any =
of=20
> > its signature.
> >
> > Regards,
> >
> > Rowan Tommins
> > [IMSoP]
>=20
> 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.
>=20
> 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.
>=20
> I've done quite a bit of dynamic dispatch work lately, and is_callable() =
and method_exists('__invoke') have sufficed for what I need.
>=20
> As an older example:
>=20
> https://github.com/php-fig/event-dispatcher-util/blob/master/src/Paramete=
rDeriverTrait.php
>=20
> 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=E2=80=99s perhaps just my opinion, because for structural and =
implementation inheritance, I=E2=80=99ve also found that method_exists(...)=
 is practical, and as is so often the case in PHP script code, =
there=E2=80=99s 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=E2=80=99m not mistaken, this =
cannot yet be declared as an extension with non-optional method parameters,=
 but that doesn=E2=80=99t 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