Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120621
MIME-Version: 1.0
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
 <CA+p1FaYU58Z7UZuDNEHnOWefZyu6uoP+4iZ7rgOhQHaA+f+_AQ@mail.gmail.com> <CAAKU0ukt+rHchFhvcEUJcY8q9UNRjoF9BxQTiWUdOanffg012Q@mail.gmail.com>
In-Reply-To: <CAAKU0ukt+rHchFhvcEUJcY8q9UNRjoF9BxQTiWUdOanffg012Q@mail.gmail.com>
Date: Mon, 19 Jun 2023 20:20:10 +0100
Message-ID: <CA+p1Fabw7We9XQNiSMKo34sZigyjnx6WF1yKXR3Xb66y_o4VYg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000016945305fe806d0a"
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: davidgebler@gmail.com (David Gebler)

--00000000000016945305fe806d0a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 19, 2023 at 3:53=E2=80=AFAM Levi Morrison <levi.morrison@datado=
ghq.com>
wrote:

>
> No, there's no attempt to ensure the method body adheres to calling
> the public interface. Due to PHP's possible dynamic behaviors, I don't
> think it's reasonable to attempt to enforce it at compile-time. I'm
> not sure it's worth the effort trying to enforce it at runtime either,
> but it would be nice to see lints from static analysis tools which
> detect this issue.
>

Okay, thanks. That's really quite significant, since it changes the feature
to one which could allow changes made to interfaces to adversely impact
existing clients of an interface without those clients changing a thing.

I was excited by the description of the RFC, but I was imagining something
more like how Java does it. Personally, this limitation (or rather lack of
it) is enough that I wouldn't support it and I'd urge anyone who can vote
to carefully consider the implications of the implementation being proposed=
.

--00000000000016945305fe806d0a--