Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125362
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 30 Aug 2024 09:15:06 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <dc51b64f-ec13-44d9-beca-e01219df3264@app.fastmail.com>
In-Reply-To: 
 <CABdc3WpCjh-P9jiqMbUT_ecc4BechT3GnJiFJJxS8Aw5nsA5SQ@mail.gmail.com>
References: 
 <CANSNCr1CdKLwmJbMNw7kKP3pA0F+njwohm6xbTMHZxgmda+bHw@mail.gmail.com>
 <CABdc3WpCjh-P9jiqMbUT_ecc4BechT3GnJiFJJxS8Aw5nsA5SQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discussion] Implementing interfaces via traits
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 30, 2024, at 1:09 AM, Micha=C5=82 Marcin Brzuchalski wrote:
> Hi Brent,
>
> wt., 27 sie 2024 o 09:28 Brent Roose <brent.roose@jetbrains.com> napis=
a=C5=82(a):
>> Good morning internals
>>=20
>>=20
>> I=E2=80=99d like to test the waters about an RFC idea: allowing trait=
s to implement interfaces, and consequently a class that uses such a tra=
it will automatically implement the interface as well.
>>=20
>>=20
>> The original idea comes from Rust, where traits can be used as types.=
 I read a very inspiring post suggested by Larry, on the topic of =E2=80=
=9Cclassic inheritance=E2=80=9D vs the way Rust and Go approach it [1]. =
The tl;dr is that both Rust and Go solve several pitfalls of classical i=
nheritance (the diamond problem and inheritance abuse), thanks to a much=
 simpler approach. In Rust=E2=80=99s case that is by using traits. If yo=
u have the time, I highly recommend reading that post, it=E2=80=99s supe=
r interesting and it gives a lot of good arguments for rethinking inheri=
tance.
>>=20
>>=20
>> Back to PHP, using traits as types seems impossible, since traits are=
 a compile-time copy/paste mechanism, which means there=E2=80=99s no typ=
e information available about them at runtime.
>>=20
>>=20
>> However, allowing traits to implement interfaces would solve this pro=
blem: these interfaces would be copied over to classes during compile-ti=
me, and the interface=E2=80=99s type information is available at runtime=
. On top of that, traits already have well-defined rules for conflict re=
solution, so we wouldn=E2=80=99t need any additional syntax to handle ed=
ge cases.
>>=20
>>=20
>> Even though PHP traits differ from Rust, PHP developers already seem =
to like the idea of being able to =E2=80=9Cattach a type to a trait=E2=80=
=9D one way or another. Let me name a couple of things that happen today:
>>=20
>>=20
>>  =E2=80=A2 Laravel often provides =E2=80=9Cdefault implementations=E2=
=80=9D for their interfaces via a trait [2]. As mentioned before, traits=
 already deal with conflict-resolution, so method collisions aren=E2=80=99=
t a blocker.
>>=20
>>  =E2=80=A2 Both PHPStan and Psalm have an annotation that forces trai=
t users to implement an interface [3], which is essentially the feature =
I=E2=80=99m describing, albeit via docblock annotations instead of prope=
r syntax.
>>=20
>>  =E2=80=A2 Even though it was not accepted, the interface default met=
hods RFC approached the problem from a different angle [4]. While a majo=
rity disagreed that interfaces should implement their own methods direct=
ly, I remember it was a heavily debated topic, and believe that approach=
ing it from the other side might be easier to accept.
>=20
> With the recent RFC proposal for Default Expressions=20
> <https://wiki.php.net/rfc/default_expression> [5], I believe it=20
> presents an excellent opportunity to revisit the Interface Default=20
> Methods proposal. The Default Expressions RFC addresses similar=20
> functionality and, when combined with an opt-in feature flag, could=20
> resolve many concerns raised during the previous discussion.

I... have no idea why you're conflating the Interface Default Methods RF=
C and the Default Expressions RFC.  They have nothing to do with each ot=
her beyond having the word "default" in their name.

I would be very much in favor of revisiting Interface Default Methods, t=
hough, as I think it would be a strong feature, and it's one found in ne=
arly all of our sibling languages at this point.  PHP is weird for not h=
aving them.  I believe that would also be a better approach than traits =
that link to interfaces, which achieves not-quite the same result with m=
ore steps.

> *Opt-In Feature Flag:* To address backward compatibility concerns, I=20
> propose the introduction of a feature flag, such as=20
> `declare(default_methods =3D 1);`, that could be applied when=20
> implementing an interface or when an interface extends another. This=20
> approach would allow developers to opt-in explicitly, preventing=20
> unintended BC breaks and ensuring that the feature is adopted carefull=
y=20
> and intentionally.

Dear god no, no more feature flags.  Remember that those affect a *file*=
, not a *class*, which are not necessarily 1:1. =20

Besides, there's an opt-in way to skip the defaults already: Implement y=
our own version.  The argument that "an interface author might introduce=
 a new method with a default that is not quite perfect for every impleme=
nting class" never carried much weight with me, as it's a fringe edge ca=
se, unlikely to happen, and easily resolvable when it does.  (Via the ex=
act same means as adding a new method without a default implementation.)

> *Complexity and Developer Experience:* While the feature could=20
> significantly improve the developer experience, it also introduces=20
> complexity in how interfaces are used. To alleviate this, the `default=
`=20
> keyword could be explicitly used to mark default methods, making it=20
> easier for developers to understand and manage. For example:
>
> interface I1 { =20
> `    default public function foo(): int { =20
>         return \PHP_INT_MAX; =20
>     } =20
> }
> `
> This explicit marking not only clarifies the intention behind the=20
> method but also aids in distinguishing between regular and default=20
> methods, simplifying the mental model required to work with interfaces.

How?  All I see here is another keyword I have to use.  It doesn't do an=
ything extra for me as a consumer of that interface.  It doesn't add dis=
ambiguation to the language, either for the engine or human readers (as =
the presence of the body does that already).  It just gives me 8 more ch=
aracters to type. =20



> Just thinking out loud here - looking forward to hearing some thoughts.

My thought is we should just pass Default Interface Methods and be done =
with it. :-)

--Larry Garfield