Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120648
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>
 <CA+p1Fabw7We9XQNiSMKo34sZigyjnx6WF1yKXR3Xb66y_o4VYg@mail.gmail.com>
 <a9ee48c8-c1cb-8278-bdc1-22b19fbf15f3@gmail.com> <CA+p1FaZfjuh472ZmUajU46BENet-mPZQM9mBdSb3uJCN0-qRiw@mail.gmail.com>
 <CAFMT4NpPcciDmp5JNjeAzFYncEc9+7U3m4wabU85CHD2xRHFjw@mail.gmail.com>
In-Reply-To: <CAFMT4NpPcciDmp5JNjeAzFYncEc9+7U3m4wabU85CHD2xRHFjw@mail.gmail.com>
Date: Tue, 20 Jun 2023 14:06:58 -0300
Message-ID: <CADK1yXLOgyaCHMVoBpqG+VG5razFv-Q9KPzgMbem4Gi+GCgA7g@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: David Gebler <davidgebler@gmail.com>, Rowan Tommins <rowan.collins@gmail.com>, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000f1cd7305fe92af4b"
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: deleugyn@gmail.com (Deleu)

--000000000000f1cd7305fe92af4b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 20, 2023 at 12:10=E2=80=AFAM Levi Morrison <levim@php.net> wrot=
e:

> > I like the idea of this RFC - in fact it's one which has been near top =
of
> > my wishlist for PHP language features for a long time - but I think thi=
s
> is
> > an issue with the proposed implementation which at the very least
> warrants
> > highlighting and discussion.
>
> I understand your concern but personally believe it's overblown. This
> problem already exists with abstract classes, but doesn't seem to be
> that much of an issue in practice. I hope static analysis can fill the
> gap here, but don't think these checks are necessary to ship this
> feature.
>

I agree that these checks would not be a requirement to ship this feature.
I was thinking even further just as a thought experiment. Let's pretend for
a second that these checks could easily be implemented, wouldn't it
actually make it worse for the language as a whole? The only place where a
method body would be forbidden to call `$this->foo()` ahead-of-time
(compile-time or runtime with special error) would be on an interface
default method. Everywhere else in the language would have the behavior of
resolving the scope of `$this` and then attempting to actually execute the
method. If the scope of `$this` has a `__call()` implementation, this would
never lead to a "FatalError method not found" scenario, making these checks
even weirder.

What I'm concluding is that although it could have been nice to not allow
these weird quirks, that ship has sailed decades ago and doing it on an
interface default implementation (even if it was possible) would just
create a major language inconsistency and it would always be best to
implement this RFC without it regardless of technical limitations.

--=20
Marco Deleu

--000000000000f1cd7305fe92af4b--