Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120432
Message-ID: <c8dcba49-2f76-1812-a9af-7930662e3b5b@bastelstu.be>
Date: Mon, 29 May 2023 20:29:40 +0200
MIME-Version: 1.0
To: internals@lists.php.net
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>
 <CA+p1FaYpnRGwG35=a3X8eBGoONvJkyLiqFgcGr+BV0_XMM61pg@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CA+p1FaYpnRGwG35=a3X8eBGoONvJkyLiqFgcGr+BV0_XMM61pg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods
 (#[\Override])
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 5/24/23 01:32, David Gebler wrote:
> 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 think this is a flawed premise: Any sort of analysis that PHP itself 
performs can also be performed in userland. IDEs and static analysis 
tools already do that. In fact the probably most-requested feature for 
PHP, Generics, is already implemented in existing userland static analyzers.

Ilija already explained the benefit of having the proposed #[\Override] 
attribute in the language and that benefit applies to all kinds of code 
analysis that could technically be (and already is) performed in userland:

It's part of the language and thus will *always* be available. If it's 
not always available, then folks who switch jobs or contribute to 
various open source projects that made a different choice with regard to 
analyzers will possibly:

- Be unable to rely on a specific check that they found useful in the 
past, because the new SA tool doesn't implement it.
- Be unable to rely on a specific check working as they learned it, 
because the new SA tool implements it differently.

Basically these developers are not working with PHP, but with PHP+Psalm, 
PHP+PHPStan or PHP+Phan or whatever new tool might come around or that I 
forgot about and they will need to (re)learn all the 
functionality/differences if a future endeavour makes a different choice.

By having it as part of the language by definition it would work 
identically for everyone and it can also be documented as part of the 
language. Developers will naturally come across it while learning PHP 
and it might be included in tutorials and so even if they never heard 
about the userland analyzers they might use it in their own code and 
reap the benefits.

As the proposal is a compile time check, the mistake would also be 
immediately apparent just by loading the class (e.g. as part of *any* 
kind of test), it is not necessary to actually execute the method in 
question. So it should be sufficiently visible and usable even in 
codebases that are in a less-than-stellar state.

In short: It should not be required to combine PHP with another tool to 
make it a usable language.

>> 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.

Yes, I believe it is beneficial for the wider audience, because folks 
might share your opinion, but not publicly speak up on the list.

> suggestion of try it as a plugin for PHPStan first
I prefer to spend my time where I believe I can make the biggest impact. 
That is PHP itself and not the analyzer that I personally prefer.

Best regards
Tim Düsterhus