Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120389
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>
In-Reply-To: <CA+kxMuRse5=y_+XKk1LyQ3MpkLan75DzbE=sxtmeiaZf7W0yLQ@mail.gmail.com>
Date: Mon, 22 May 2023 22:32:19 +0100
Message-ID: <CA+p1FaZmagr9Js_a2wp2SOrbhb-uZAhcknXKRLQHonw45gBBOg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000bdcf105fc4f0216"
Subject: Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])
From: davidgebler@gmail.com (David Gebler)

--0000000000000bdcf105fc4f0216
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 22, 2023 at 1:01=E2=80=AFPM Dan Ackroyd <Danack@basereality.com=
> wrote:

> Even for those who use static analysis, most (afaik) don't have it
> running constantly in local development and this RFC would prevent
> people wondering why their code is behaving surprisingly before it is
> static analysed.
>

It takes care of one possible surprise they might encounter as a result of
not running static analysis of their code prior to runtime. Just one, out
of dozens of possible types of inference which are done by static analysis
checks and could hypothetically be done by PHP at runtime. But I'd question
whether there's an appetite out there in general to start adding all sorts
of new runtime checks, which I would argue means any new runtime check
warrants the utmost consideration of cost-benefit.


> Also, not everyone uses static analysis tools.
>

That's because PHP is a dynamic language which doesn't have an explicit
compilation step and by extension where static analysis of any sort is
optional. That's my question around the benefit with this RFC; either you
use static analysis tools as part of your PHP workflow, because you care
about that stuff, or you don't. If you do, you don't need any new error or
warning emitting behaviour added to the engine itself, you just need
PHPStan / Psalm / IDE / whatever to flag it. If you don't habitually use
these tools already, you're probably not going to be annotating your code
with #[Override] anyway.

My wager is the kind of people and teams who would be most interested in
using and would benefit most from an #[Override] attribute are the kinds of
people who are using static analysis tools and probably have configured
PHPStorm / other IDE of choice to run those checks when a file changes, or
via commit hook, or build pipeline, or whatever else. What I see here,
then, is a perfect candidate for a userland attribute.

Anyway, usual disclaimer applies; I'm not a voter on RFCs, I'm one man with
an opinion, my opinion only matters insofar as gathering a range of
community feedback matters to the author and interested members of
internals.

-Dave

--0000000000000bdcf105fc4f0216--