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
