# [VOTE] [RFC] Final anonymous classes - Thread: https://externals.io/message/121906 - Original archive: https://news-web.php.net/php.internals/121906 - Started by Daniil Gentili on 2023-12-03T10:40:35+00:00 - Messages: 10 - RFC: Final by default anonymous classes (Declined) — https://externals.io/rfc/final_by_default_anonymous_classes.md - RFC: Final anonymous classes (Declined) — https://externals.io/rfc/final_anonymous_classes.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #121906 — Daniil Gentili — 2023-12-03T10:40:35+00:00 URL: https://externals.io/message/121906#121906 Hi all, I've just opened voting for the final anonymous classes RFC @ https://wiki.php.net/rfc/final_anonymous_classes. Voting started now, and will run until December 18th 2023, 00:00 GMT. Regards, Daniil Gentili. --- ## #121909 — Nikita Popov — 2023-12-03T14:49:12+00:00 URL: https://externals.io/message/121906#121909 · In reply to: #121906 > Hi all, > > I've just opened voting for the final anonymous classes RFC @ > https://wiki.php.net/rfc/final_anonymous_classes. > > Voting started now, and will run until December 18th 2023, 00:00 GMT. For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. It makes very little sense to me that everyone needs to explicitly mark their anonymous classes as final just because there is a class_alias loophole that could, in theory, have been used to extend anonymous classes in the past. Especially given that there is no evidence of this "feature" being used in the wild (or if there is such evidence, it was not presented in the proposal). Regards, Nikita --- ## #121910 — Daniil Gentili — 2023-12-03T15:02:30+00:00 URL: https://externals.io/message/121906#121910 · In reply to: #121909 Hi Nikita, > For the record, I've voted against this proposal because I believe it > should have gone with option 2, that is to *always* make anonymous > classes final. > > It makes very little sense to me that everyone needs to explicitly > mark their anonymous classes as final just because there is a > class_alias loophole that could, in theory, have been used to extend > anonymous classes in the past. Especially given that there is no > evidence of this "feature" being used in the wild (or if there is such > evidence, it was not presented in the proposal). > Should I amend the RFC, recreating the current poll with three mutually exclusive options (final anonymous classes, final by default without open, final by default with open) instead of just Yes/No (I personally share your PoV, but given the minor pushback received in the last discussion thread I initially decided against it), could that be done without restarting the discussion process? Regards, Daniil Gentili. --- ## #121911 — Nicolas Grekas — 2023-12-03T15:05:58+00:00 URL: https://externals.io/message/121906#121911 · In reply to: #121909 Hello Nikita, > > […] > > For the record, I've voted against this proposal because I believe it > should have gone with option 2, that is to *always* make anonymous classes > final. > > It makes very little sense to me that everyone needs to explicitly mark > their anonymous classes as final just because there is a class_alias > loophole that could, in theory, have been used to extend anonymous classes > in the past. Especially given that there is no evidence of this "feature" > being used in the wild (or if there is such evidence, it was not presented > in the proposal). > You might have missed my message in the discussion thread, see https://externals.io/message/121685#121690 There is such evidence (not in the RFC though). Nicolas --- ## #121912 — Nikita Popov — 2023-12-03T15:42:05+00:00 URL: https://externals.io/message/121906#121912 · In reply to: #121911 > Hello Nikita, > > > […] > > You might have missed my message in the discussion thread, > > see https://externals.io/message/121685#121690 > > There is such evidence (not in the RFC though). Thanks, I did indeed miss this. However, I also don't think that a test-only use is particularly compelling. If this were something that Symfony had exposed as a public API promise, we might be caught between a rock and a hard place, but this thankfully doesn't seem to be the case. I think I can fairly confidently say that the ability to extend anonymous classes by abusing class_alias is a bug in the original implementation, rather than an intentional feature. Yes, people do start to depend on bugs if they exist for long enough, but I don't think this means we shouldn't fix them (within the bounds of pragmatism). Regards, Nikita --- ## #121914 — Derick Rethans — 2023-12-03T16:34:47+00:00 URL: https://externals.io/message/121906#121914 · In reply to: #121909 > > > […] > >For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. > >It makes very little sense to me that everyone needs to explicitly mark their anonymous classes as final just because there is a class_alias loophole that could, in theory, have been used to extend anonymous classes in the past. Especially given that there is no evidence of this "feature" being used in the wild (or if there is such evidence, it was not presented in the proposal). > >Regards, >Nikita I agree with this, and would also say that this RFC is the most thin one I've seen. There is no reasoning, or examples, or pretty much anything else in it. cheers Derick --- ## #121915 — Sebastian Bergmann — 2023-12-03T16:36:33+00:00 URL: https://externals.io/message/121906#121915 · In reply to: #121909 Am 03.12.2023 um 15:49 schrieb Nikita Popov: > For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. I voted "no" for exactly the same reason. --- ## #121916 — Larry Garfield — 2023-12-03T18:34:51+00:00 URL: https://externals.io/message/121906#121916 · In reply to: #121914 > > > […] > I agree with this, and would also say that this RFC is the most thin > one I've seen. > > There is no reasoning, or examples, or pretty much anything else in it. I have also voted no for the same reasons as above. A more fleshed out RFC that goes default-final (which would then enable the engine optimizations mentioned) I would probably vote yes for. Though one could debate if that should be saved for 9.0 just to be safe. (Which I'd also be fine with.) --Larry Garfield --- ## #121917 — Andreas Heigl — 2023-12-03T18:47:42+00:00 URL: https://externals.io/message/121906#121917 · In reply to: #121916 Am 03.12.23 um 19:34 schrieb Larry Garfield: > > > […] > > I have also voted no for the same reasons as above. A more fleshed out RFC that goes default-final (which would then enable the engine optimizations mentioned) I would probably vote yes for. Though one could debate if that should be saved for 9.0 just to be safe. (Which I'd also be fine with.) I also voted NO for the same reason. But also because I am missing a few things in the RFC. I am especially missing a reasoning as to why final for anonymous classes is a thing in the first place. What pain is this RFC adressing? (Apart from not being able to write `new final class{}`) Also I'd expect all the relevant information from the discussion to be in the RFC so that we can figure out what the main points were without having to dig through Mailinglists or PRs. Cheers Andreas -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org https://hei.gl/where | | https://hei.gl/pubkeyandreas | +---------------------------------------------------------------------+ --- ## #121933 — Daniil Gentili — 2023-12-05T18:31:47+00:00 URL: https://externals.io/message/121906#121933 · In reply to: #121906 Hi all, Thanks for the feedback, sorry the RFC was a bit too thin, given the multiple internals threads I started on the topic, including the latest [RFC] discussion thread, I mistakenly assumed that everyone was already familiar with the topic, even if by just lurking. To reply to some of the feedback received in this thread, >I am especially missing a reasoning as to why final for anonymous classes is a thing in the first place. What pain is this RFC adressing? The only real pain I was addressing was indeed the inability to enable some possible opcache optimizations when using final classes, as mentioned in the Proposal section; I believe that that is reason enough to add support for a minor feature like this. >There is no reasoning, or examples Added some more reasoning, even though as said both here and the RFC, the reason behind the RFC is quite simple, just allow using some optimizations that were excluded due to an oversight in the original implementation of anonymous classes. Regarding the examples I again mistakenly assumed that everyone was already familiar with the (rather basic) patch and the examples in the testsuite, corrected that mistake now. Regarding the voting options, after feedback received in the last [RFC] discussion thread from Nicolas Grekas: >Hi Daniil, > > […] option. > > […] PHP. > > […] > > […] 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 :). > > […] > Daniil Gentili >I think this is a dangerous game. Breaking BC shouldn't be proposed unless absolutely needed IMHO. >Nicolas I had moved a large chunk of the rationale and removed basically all the alternative polls I had initially planned to propose; the initial text of the RFC can be seen at the bottom, in the newly updated Rejected Features section (https://wiki.php.net/rfc/final_anonymous_classes). I've also added some additional pro and counterpoints on my own. As I see now, it was a mistake to remove the other two planned voting options just based on a single feedback, thus I would like to ask, would it be OK to add back the two voting options I removed basically a day before opening voting, with end date @ 2023-12-20? Here are the options I removed a few days ago, and would like to add back: - Make all anonymous classes final by default, without the option to make them final? - Yes/No - Make all anonymous classes final by default, provide an optional ''open'' keyword to make them non-final - Yes/No Again to clarify, the voting options would be mutually exclusive as proposed in the original version of the RFC. Regards, Daniil Gentili.