Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120589
MIME-Version: 1.0
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
 <648AAE1D.9070805@adviesenzo.nl>
In-Reply-To: <648AAE1D.9070805@adviesenzo.nl>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Thu, 15 Jun 2023 08:52:09 -0600
Message-ID: <CAAKU0uk=tKzzaGRJAF+7WaT-3CbCwjJbHFbc4WCqCRK_9+OOgw@mail.gmail.com>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: internals@lists.php.net ("Levi Morrison via internals")

On Thu, Jun 15, 2023 at 12:22=E2=80=AFAM Juliette Reinders Folmer
<php-internals_nospam@adviesenzo.nl> wrote:
>
> On 15-6-2023 5:47, Levi Morrison via internals wrote:
> > I am moving my RFC for interface default methods to discussion:
> > https://wiki.php.net/rfc/interface-default-methods.
>
> There are two things I'm missing on an initial read of the RFC.
>
>  > Adding a default implementation to an existing interface method will
> not break existing code, because every existing usage has a higher
> priority than the default.
>
> A: How would this work if the existing method in the implementing class
> has a different function signature than the newly introduced method in
> the interface ?
> There are two aspects to this:
> 1. What if the existing method has different parameters ?
> 2. What if the existing method has the same parameters, but
> different/incompatible parameter/return types ?

You mis-interpreted what I was trying to say, so I'll try to clarify
that first, and then secondly address your question.

If there an existing interface, say:

    interface Interface1 { function method1(); }

The RFC is saying that if you added a default implementation to
`method1` without changing its signature at all, then that would not
be a compatibility issue. All existing implementers have somehow
implemented this method already, so adding a default will do nothing
(it will be unused).

As to your questions about incompatible signatures, it's not any
different from any other interface method. If you add a new method to
the interface, and it's not compatible with some existing method on an
implementer, then it's a compatibility issue. That's not changing with
default methods. What is changing is that if a new method is added to
an interface, and it has a default implementation, it's way less
likely to be a compatibility break, because we only have to worry
about methods that share the same name. Without default methods,
essentially all additions would be compatibility break.

> B: How does the ability to add default method implementations to an
> interface compare to providing an abstract class implementing the
> interface and providing the default method implementations ?

A key difference is that you can implement many interfaces, but can
only extend a single class (abstract or not). For this reason, many
contracts are formed with interfaces and relatively fewer with
abstract classes. Well, that's my experience, anyway.