Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120395
MIME-Version: 1.0
References: <e58dde83-654d-b0ad-de77-d0450a56ef75@bastelstu.be>
 <CADyq6sJ3aaipfagKtoqksOm2JFp-UN5H0hkrOndgKad2W9x3fg@mail.gmail.com>
 <CA+p1FabKB1K2P9ZidyNgva+mfe1xzTtracyKkQGFKeWYcW1+_Q@mail.gmail.com>
 <CA+kxMuRse5=y_+XKk1LyQ3MpkLan75DzbE=sxtmeiaZf7W0yLQ@mail.gmail.com>
 <CA+p1FaZmagr9Js_a2wp2SOrbhb-uZAhcknXKRLQHonw45gBBOg@mail.gmail.com> <c2ea6b97-5ecd-ca12-c748-f0b5e37402c4@bastelstu.be>
In-Reply-To: <c2ea6b97-5ecd-ca12-c748-f0b5e37402c4@bastelstu.be>
Date: Wed, 24 May 2023 00:32:20 +0100
Message-ID: <CA+p1FaYpnRGwG35=a3X8eBGoONvJkyLiqFgcGr+BV0_XMM61pg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002b261c05fc64cdcc"
Subject: Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])
From: davidgebler@gmail.com (David Gebler)

--0000000000002b261c05fc64cdcc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 23, 2023 at 9:27=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.b=
e> wrote:

> Just to make sure there is no misunderstanding I'd like to clarify that
> the proposed check of this RFC is not a runtime error. It's a compile
> time error, just like the check for incompatible method signatures
> during inheritance. In fact it shares a non-trivial amount of the
> existing logic of that check, because it's so similar.
>
> My understanding is that once the class is successfully sitting in
> Opcache there will not be any further overhead.
>

I figured as much, I say runtime just to differentiate from compiled
languages with a similar feature. Although OPcache is ubiquitous in
production environments now, it's not obligated and the cache only lasts as
long as the SAPI process. It's not overhead I think is the issue, anyway -
at least not off adding "one more thing" at this stage, it's more the
precedent of is there a sufficient benefit to adding this and potentially
more features like it at the language-level.

Merely delineating intent isn't something I feel warrants a change in the
language, particularly when you'd need SAs and IDEs to implement it anyway
for users to not be caught out with a fatal error at runtime (/compile
time).
Don't get me wrong; *delineating intent is a good thing*. I entirely get
where you're coming from, however I'd refer back to my earlier comment: any
attributes added in the engine should provide a tangible benefit which
*can't be achieved in userland*.


> I'll put the email back on unread and hope to
> be able to give a more expanded and nuanced reply later.
>

Do this if you feel it's beneficial to the wider audience of internals to
better understand the motivation and justification for your proposal, but
ultimately it's not me you need to persuade so certainly don't worry about
getting into further nuances on my account.

I don't have any more feedback or thoughts for you until/unless the RFC
changes, so I'll finish by saying for me, I'd either back Marco's
suggestion of try it as a plugin for PHPStan first, or expand your proposal
more along the lines of what Sara's suggested.

Thanks.

-Dave

--0000000000002b261c05fc64cdcc--