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

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to