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_classes
>
> I'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
