rfc:final_anonymous_classes
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:final_anonymous_classes [2023/12/03 10:34] – danog | rfc:final_anonymous_classes [2023/12/23 15:04] (current) – danog | ||
---|---|---|---|
Line 2: | Line 2: | ||
* Date: 2023-11-15 | * Date: 2023-11-15 | ||
* Author: Daniil Gentili < | * Author: Daniil Gentili < | ||
- | * Status: | + | * Status: |
===== Introduction ===== | ===== Introduction ===== | ||
Line 13: | Line 13: | ||
This should also allow some additional opcache optimizations, | This should also allow some additional opcache optimizations, | ||
+ | |||
+ | Example syntax: | ||
+ | |||
+ | <code php> | ||
+ | $x = new final class {}; | ||
+ | </ | ||
+ | |||
+ | Extending a final anonymous class throws an error: | ||
+ | |||
+ | <code php> | ||
+ | $x = new final class {}; | ||
+ | class_alias($x:: | ||
+ | class aliasExtends extends alias {} | ||
+ | </ | ||
+ | |||
+ | '' | ||
+ | Fatal error: Class aliasExtends cannot extend final class class@anonymous in %s on line %d | ||
+ | '' | ||
+ | |||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Line 30: | Line 49: | ||
2/3 required to accept. Voting started on 2023-12-03 and will end on 2023-12-18 00:00 GMT. | 2/3 required to accept. Voting started on 2023-12-03 and will end on 2023-12-18 00:00 GMT. | ||
- | <doodle title=" | + | <doodle title=" |
* Yes | * Yes | ||
* No | * No | ||
Line 42: | Line 61: | ||
* Pull request discussion: https:// | * Pull request discussion: https:// | ||
- | * Internals discussion: https:// | + | * Internals discussion: https:// |
===== Rejected Features ===== | ===== Rejected Features ===== | ||
+ | |||
+ | After feedback received from Nikolas Grekas in the last [RFC] discussion thread (https:// | ||
+ | |||
+ | < | ||
+ | Hi Daniil, | ||
+ | |||
+ | >> 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. | ||
+ | >> Cheers, | ||
+ | >> Nicolas | ||
+ | |||
+ | > 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 | ||
+ | |||
+ | I think this is a dangerous game. Breaking BC shouldn' | ||
+ | |||
+ | | ||
+ | </ | ||
+ | |||
+ | To be entirely honest, I'm a bit on the fence: on one hand, looking at code like '' | ||
+ | |||
+ | - Has a name (even if it's not immediately obvious) | ||
+ | - Can be referenced to using its name ('' | ||
+ | |||
+ | seems a tad bit too restrictive... | ||
+ | |||
+ | On the other hand, I also really don't like non-final classes, in all of my projects, I use CS rules that force all classes to either be abstract or final, because unfortunately, | ||
+ | |||
+ | Still, there are some useful patterns, mainly regarding testing and mocking, for example I use https:// | ||
+ | |||
+ | This is why I remain ambivalent about the options, as seen both in my emails and in the original text of the RFC: | ||
Personally, I would have instead preferred the much cleaner approach of making all anonymous classes final by default, (preferrably) without offering the option to make them non-final. | Personally, I would have instead preferred the much cleaner approach of making all anonymous classes final by default, (preferrably) without offering the option to make them non-final. |
rfc/final_anonymous_classes.1701599661.txt.gz · Last modified: 2023/12/03 10:34 by danog