Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129140
Precedence: list
MIME-Version: 1.0
Date: Fri, 7 Nov 2025 12:30:41 -0800
Message-ID: <CAOHeFxeYjxfSM_0S-HSCEf_OZYa9E9MvQM2CPKENn+3VrHgToA@mail.gmail.com>
Subject: [PHP-DEV] Re: Pre-RFC proposal: opt-in implicit interfaces / structural typing
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000cd02c50643070e4b"
From: malone.spencer@gmail.com (Spencer Malone)

--000000000000cd02c50643070e4b
Content-Type: text/plain; charset="UTF-8"

Apologies for the top post, I'll... have to get used to that.

> I could see implicit interfaces working in conjunction with extension
functions, if we can figure those out.  I'm not sure if they offer much
value without them, given the state of PHP.  It would basically mean you
have to opt-out of a type rather than opt-in, as now.  That could get...
weird.

I'm not sure I understand why the value on this is low without extension
functions or why we would need the ability to opt-out. In my day to day, I
saw this most commonly being utilized for:

1) I'm working with a class that is probably oversized, but I only care
about a thin part of the functionality, but I don't have a clear way to add
an interface to that class which defines the contract I need. Using an
implied interface in this case helps me thin out the contract to what I
need, and that makes testing much easier as I can mock only those relevant
functions. This would be resolvable with the original class being better
designed, but that's not always an option. On the testing side this is kind
of made easier with partial mocks, but those can trigger all sorts of side
effects that aren't much fun to work with in my experience.

2) The joining of common interfaces for easier introduction of
interoperable interfaces, thinking about PSR-11 not tackling the
configuration of entities, or how some of the interfaces look on the
symfony cache packages.

3) Clearer definition of "duck-typing" like behaviors into the function
signature. This is stuff we already see in PHP (`if (method_exists(<bla
bla>)`), but to me it would improve clarity if these requirements were in
the parameter and property definitions, instead of in the function body.

All 3 of these (at least to me) seem improved with this path and high
value, but I'm worried I may be missing something.

To me in these cases, if someone bumps into mistaken typing, that's
generally on the caller. Explicit interfaces do guarantee that anyone
opting into that contract is doing it for the intended reasons, but if
you're working with an implicit interface it becomes the function caller's
responsibility to ensure they are making wise decisions on what gets passed
in. I don't think this is a new problem set since it exists with the
current duck typing patterns, all we've done is more clearly defined our
expectations on what functions exist without a lot of manual
`method_exists`/`property_exists`

- Spencer

--000000000000cd02c50643070e4b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>Apologies for the top post, I&#39;ll..=
. have to get used=C2=A0to that.</div><div><br></div>&gt; I could see impli=
cit interfaces working in conjunction with extension functions, if we can f=
igure those out.=C2=A0 I&#39;m not sure if they offer much value without th=
em, given the state of PHP.=C2=A0 It would basically mean you have to opt-o=
ut of a type rather than opt-in, as now.=C2=A0 That could get... weird.<br>=
<div><br></div><div>I&#39;m not sure I understand why the value on this is =
low without extension functions or why we would need the ability to opt-out=
. In my day to day, I saw this most commonly being utilized for:</div><div>=
<br></div><div>1) I&#39;m working with a class that is probably oversized, =
but I only care about a thin part of the functionality, but I don&#39;t hav=
e a clear way to add an interface to that class which=C2=A0defines the cont=
ract I need. Using an implied interface in this case helps me thin out the =
contract to what I need, and that makes testing much easier as I can mock o=
nly those relevant functions. This would be resolvable with the original cl=
ass being better designed, but that&#39;s not always an option. On the test=
ing side this is kind of made easier with partial mocks, but those can trig=
ger all sorts of side effects that aren&#39;t much fun to work with in my e=
xperience.</div><div><br></div><div>2) The joining of common interfaces for=
 easier introduction of interoperable=C2=A0interfaces, thinking about PSR-1=
1 not tackling the configuration of entities, or how some of the interfaces=
 look on the symfony cache packages.</div><div><br></div><div>3) Clearer de=
finition of &quot;duck-typing&quot; like behaviors into the function signat=
ure. This is stuff we already see in PHP (`if (method_exists(&lt;bla bla&gt=
;)`), but to me it would improve clarity if these requirements were in the =
parameter and property definitions, instead of in the function body.</div><=
div><br></div><div>All 3 of these (at least to me) seem improved with this =
path and high value, but I&#39;m worried I may be missing something.</div><=
div><br></div><div>To me in these cases, if someone bumps into mistaken typ=
ing, that&#39;s generally on the caller. Explicit interfaces do guarantee t=
hat anyone opting into that contract is doing it for the intended reasons, =
but if you&#39;re working with an implicit interface it becomes the functio=
n caller&#39;s responsibility to ensure they are making wise decisions on w=
hat gets passed in. I don&#39;t think this is a new problem set=C2=A0since =
it exists with the current duck typing patterns, all we&#39;ve done is more=
 clearly defined our expectations on what functions exist without a lot of =
manual `method_exists`/`property_exists`</div><div><br></div><div>- Spencer=
</div></div>

--000000000000cd02c50643070e4b--