Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130485
Precedence: list
MIME-Version: 1.0
References: <CABE7Eu8wTLhVD4+xfcK-ZB10on5cRszKuWSaM45ncVBkBO99iw@mail.gmail.com>
 <5ce1f5a3-1ad5-4cc7-8c6e-93170af28ef4@sandfox.me>
In-Reply-To: <5ce1f5a3-1ad5-4cc7-8c6e-93170af28ef4@sandfox.me>
Date: Mon, 30 Mar 2026 02:32:24 +0200
Message-ID: <CABE7Eu-B-VpwhapmcG342cq52JkbzyPSkf=7sR6QmZ0-7Z9+Ww@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC proposal: Invokable interface
To: Anton Smirnov <sandfox@sandfox.me>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c4f705064e32fc72"
From: aldemeery@gmail.com (Osama Aldemeery)

--000000000000c4f705064e32fc72
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Anton,

Thank you for taking the time to respond.
This is really helpful feedback, and I genuinely think the distinction
you're drawing is an important one to get right.

I think the parallel with Stringable holds more closely than it might seem.
If we put them side by side:

   - Both are automatically implemented by the engine for classes that
   define the corresponding magic method.
   - Both can be explicitly implemented by users.
   - Both enforce the presence of a magic method. Stringable enforces
   __toString(), Invokable enforces __invoke().
   - The argument that magic methods are just implementation details holds
   true for both.

The only difference is that __toString() has a fixed signature, so
Stringable can enforce it through a normal interface declaration.
__invoke() doesn't
have a fixed signature, so Invokable uses an enforcement handler instead.
Different mechanism, same contract. The difference is caused by the
variable signature, not by any fundamental difference in what the interface
represents.

The comparison to Throwable is interesting, but as far as I understand (and
please correct me if I am wrong), Throwable restricts direct user
implementation by design to keep the exception hierarchy clean and
predictable.

That said, I could be wrong about any of this, and in which case I would
genuinely appreciate you correcting my reasoning.

Regards,

Osama Aldemeery

On Mon, Mar 30, 2026 at 12:52=E2=80=AFAM Anton Smirnov <sandfox@sandfox.me>=
 wrote:

> Hi!
>
> On 30/03/2026 00:42, Osama Aldemeery wrote:
> > It follows the Stringable pattern: auto-implemented for any class
> > defining __invoke(), explicitly implementable with enforcement, and
> > covariant to callable in return type checks.
>
> Stringable is just a normal interface that can be used directly as any
> other regular interface, it's just also applied magically.
>
> Invokable cannot be a regular interface because the signature for
> __invoke is not fixed, so it's a "weird" interface with magic behavior
> like Throwable and Iterable. What is common about these weird interfaces
> is that they can't be directly implemented by user. I don't feel like
> breaking this rule is a good idea for something with no clear benefits.
>
> Second thing is that magic methods are not supposed to be used directly,
> so having __invoke is just an implementation detail, the consumer code
> should not check for that, that's a code smell.
>
> Anton
>

--000000000000c4f705064e32fc72
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Anton,<br><br>Thank you for taking the time to respond.<br=
>This is really helpful feedback, and I genuinely think the distinction you=
&#39;re drawing is an important one to get right.<br><br>I think the parall=
el with=C2=A0<span style=3D"color:rgb(101,109,118);font-family:monospace;fo=
nt-size:9.50625px;background-color:rgba(175,184,193,0.2)">Stringable</span>=
=C2=A0holds more closely than it might seem.<br>If we put them side by side=
:<br><ul><li>Both are automatically implemented by the engine for classes t=
hat define the corresponding magic method.<br></li><li>Both can be explicit=
ly implemented by users.</li><li>Both enforce the presence of a magic metho=
d.=C2=A0<code style=3D"color:rgb(101,109,118);background-color:rgba(175,184=
,193,0.2);padding:2px 4px;border-radius:3px;word-break:break-word;font-size=
:0.9em">Stringable</code>=C2=A0enforces=C2=A0<code style=3D"color:rgb(101,1=
09,118);background-color:rgba(175,184,193,0.2);padding:2px 4px;border-radiu=
s:3px;word-break:break-word;font-size:0.9em">__toString()</code>,=C2=A0<cod=
e style=3D"color:rgb(101,109,118);background-color:rgba(175,184,193,0.2);pa=
dding:2px 4px;border-radius:3px;word-break:break-word;font-size:0.9em">Invo=
kable</code>=C2=A0enforces=C2=A0<code style=3D"color:rgb(101,109,118);backg=
round-color:rgba(175,184,193,0.2);padding:2px 4px;border-radius:3px;word-br=
eak:break-word;font-size:0.9em">__invoke()</code>.</li><li>The argument tha=
t magic methods are just implementation details holds true for both.</li></=
ul><div>The only difference is that=C2=A0<span style=3D"color:rgb(101,109,1=
18);font-family:monospace;font-size:9.50625px;background-color:rgba(175,184=
,193,0.2)">__toString()</span>=C2=A0has a fixed signature, so=C2=A0<span st=
yle=3D"color:rgb(101,109,118);font-family:monospace;font-size:9.50625px;bac=
kground-color:rgba(175,184,193,0.2)">Stringable</span>=C2=A0can enforce it =
through a normal interface declaration.=C2=A0<span style=3D"color:rgb(101,1=
09,118);font-family:monospace;font-size:9.50625px;background-color:rgba(175=
,184,193,0.2)">__invoke()</span>=C2=A0doesn&#39;t have a fixed signature, s=
o=C2=A0<span style=3D"color:rgb(101,109,118);font-family:monospace;font-siz=
e:9.50625px;background-color:rgba(175,184,193,0.2)">Invokable</span>=C2=A0u=
ses an enforcement handler instead.<br>Different mechanism, same contract. =
The=C2=A0difference is caused by the variable signature, not by any fundame=
ntal difference in what the interface represents.<br><br>The comparison to=
=C2=A0<span style=3D"color:rgb(101,109,118);font-family:monospace;font-size=
:9.50625px;background-color:rgba(175,184,193,0.2)">Throwable</span>=C2=A0is=
 interesting, but as far as I understand (and please correct me if I am wro=
ng),=C2=A0<span style=3D"color:rgb(101,109,118);font-family:monospace;font-=
size:9.50625px;background-color:rgba(175,184,193,0.2)">Throwable</span>=C2=
=A0restricts direct user implementation by design to keep the exception hie=
rarchy clean and predictable.<br><br>That said, I could be wrong about any =
of this, and in which case I would genuinely appreciate you correcting my r=
easoning.<br><br>Regards,<br><br>Osama Aldemeery</div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Mon, Mar 30, 2026 at 12:52=E2=80=AFAM Anton Smirnov &lt;<a href=3D"mai=
lto:sandfox@sandfox.me">sandfox@sandfox.me</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Hi!<br>
<br>
On 30/03/2026 00:42, Osama Aldemeery wrote:<br>
&gt; It follows the Stringable pattern: auto-implemented for any class <br>
&gt; defining __invoke(), explicitly implementable with enforcement, and <b=
r>
&gt; covariant to callable in return type checks.<br>
<br>
Stringable is just a normal interface that can be used directly as any <br>
other regular interface, it&#39;s just also applied magically.<br>
<br>
Invokable cannot be a regular interface because the signature for <br>
__invoke is not fixed, so it&#39;s a &quot;weird&quot; interface with magic=
 behavior <br>
like Throwable and Iterable. What is common about these weird interfaces <b=
r>
is that they can&#39;t be directly implemented by user. I don&#39;t feel li=
ke <br>
breaking this rule is a good idea for something with no clear benefits.<br>
<br>
Second thing is that magic methods are not supposed to be used directly, <b=
r>
so having __invoke is just an implementation detail, the consumer code <br>
should not check for that, that&#39;s a code smell.<br>
<br>
Anton<br>
</blockquote></div>

--000000000000c4f705064e32fc72--