Hi all,
I would like to submit an RFC and PR to add support for final anonymous
classes, /or/ make all anonymous classes final by default, with or
without the possibility to make them non-final.
Here's the URL of the RFC: https://wiki.php.net/rfc/final_anonymous_classes
I'd more more than glad to receive some feedback!
Regards,
Daniil Gentili.
Hi Daniil and thanks for the RFC.
I would like to submit an RFC and PR to add support for final anonymous
classes, /or/ make all anonymous classes final by default, with or
without the possibility to make them non-final.Here's the URL of the RFC:
https://wiki.php.net/rfc/final_anonymous_classesI'd more more than glad to receive some feedback!
I've read the RFC proposing to make anonymous classes final by default, and
as defender of backward compatibility, I have concerns. The RFC cites
potential performance gains and a cleaner codebase as justifications.
However, the performance improvement seems limited to a narrow use case –
anonymous classes aren't that common in everyday PHP coding. Without
concrete data demonstrating significant performance benefits, this argument
doesn't seem strong enough to warrant a BC break.
Regarding the argument for cleaner code, while I acknowledge the appeal of
streamlined design, we must remember that breaking backward compatibility
isn't the right tool for correcting past decisions. PHP has a rich history
of handling such transitions gracefully, typically introducing changes with
a deprecation notice in a minor version before a major shift. This approach
has served our community well, maintaining stability and predictability.
Is this change truly worth such a departure from our norms? I believe not.
Making anonymous classes final by default goes against the principle of
least surprise, a core philosophy in PHP where regular classes aren't final
by default.
While I'm open to Proposal 1, which introduces final anonymous classes
without breaking BC, Proposals 2 and 3 are a different story. They seem to
suggest we can break backward compatibility on a whim, but our release
process (https://wiki.php.net/rfc/releaseprocess) clearly advises against
such moves in minor releases. Overriding this policy should require a more
substantial rationale.
As an example, in my work with Symfony, I've utilized class_alias to extend
anonymous classes within a test suite (
https://github.com/symfony/symfony/blob/c9e7809f045a1366afe2c2643bae15751ae7b500/src/Symfony/Component/VarExporter/Tests/LazyProxyTraitTest.php#L294).
While the RFC suggests alternative methods to achieve something similar,
the essence of preserving backward compatibility is about ensuring
stability and reliability without imposing the burden of code modification
on userland.
In summary, I advocate for the RFC to focus on the non-BC-breaking option.
Let's maintain our commitment to stability and gradual evolution in PHP.
Cheers,
Nicolas
Hi,
While I'm open to Proposal 1, which introduces final anonymous classes
without breaking BC, Proposals 2 and 3 are a different story.
In summary, I advocate for the RFC to focus on the non-BC-breaking option.
Let's maintain our commitment to stability and gradual evolution in PHP.
Agree with your points, just adding final anonymous classes seems the best solution to me, but given the interest in alternative solutions both in the pull request discussion, and in the previous mailing list thread, I think I'll leave the other options in the RFC, to see how the votes will go (I'm actually curious myself :).
Regards,
Daniil Gentili.
Hi all,
Heads up, I'll move this RFC
(https://wiki.php.net/rfc/final_anonymous_classes) to voting status
tomorrow!
Regards,
Daniil Gentili.
Hi all,
Heads up, I'll move this RFC
(https://wiki.php.net/rfc/final_anonymous_classes) to voting status
tomorrow!Regards,
Daniil Gentili.
The way the vote is structured there is highly confusing. Three separate primary votes, and then you'd plan a separate runoff RFC? That... is needlessly complicated.
Pick an approach and put that up for a vote, or figure out how to structure it as a secondary vote. Or make it a 4 item RCV vote (with one of the options being "do nothing"). There's a couple of ways to handle it, but the way it's written now is not it.
--Larry Garfield