# Final anonymous classes - Thread: https://externals.io/message/121356 - Original archive: https://news-web.php.net/php.internals/121356 - Started by Daniil Gentili on 2023-10-17T17:06:37+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 --- ## #121356 — Daniil Gentili — 2023-10-17T17:06:37+00:00 URL: https://externals.io/message/121356#121356 Hi everyone, I'd like to submit an RFC to add support for final anonymous classes. This should also allow some additional opcache optimizations. I've already prepared the implementation at https://github.com/php/php-src/pull/11126, what do you think? 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. However, I understand that this might be a little bit too restrictive for something that may have some valid usecases, even if extending anonymous classes currently requires some hack-ish workarounds with class_alias. All in all, as per the title, I'd just like to add support for final anonymous classes (new final class {}), without changing any existing semantics. What do you think? Thanks, Daniil Gentili. --- ## #121357 — Saki Takamachi — 2023-10-17T17:31:28+00:00 URL: https://externals.io/message/121356#121357 · In reply to: #121356 Hi, Daniil > 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. > > However, I understand that this might be a little bit too restrictive for something that may have some valid usecases, even if extending anonymous classes currently requires some hack-ish workarounds with class_alias. > > > All in all, as per the title, I'd just like to add support for final anonymous classes (new final class {}), without changing any existing semantics. I think the default can be made final. This is because it is difficult to consider such complex "hack" operations as "features supported by the language." This is even considered a bug of some kind. If more "realistic" code examples were available, the conclusion would be different. At least, as far as I can currently understand, I don't think there is any need to consider backward compatibility with such "hacks". Regards. Saki --- ## #121382 — tim@bastelstu.be — 2023-10-18T12:26:36+00:00 URL: https://externals.io/message/121356#121382 · In reply to: #121356 Hi > 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. > > However, I understand that this might be a little bit too restrictive > for something that may have some valid usecases, even if extending > anonymous classes currently requires some hack-ish workarounds with > class_alias. > Perhaps make it two votes, each requiring a 2/3 majority? 1. Allow the 'final' keyword on anonymous classes? 2. Enforce that all anonymous classes are final? Best regards Tim Düsterhus --- ## #121384 — Robert Landers — 2023-10-18T12:35:28+00:00 URL: https://externals.io/message/121356#121384 · In reply to: #121382 > > Hi > > > > […] Hello, > Perhaps make it two votes, each requiring a 2/3 majority? > > 1. Allow the 'final' keyword on anonymous classes? > 2. Enforce that all anonymous classes are final? How would someone make an anonymous class "unfinal"? I've used this "hack" in unit tests, many times. It's quite useful, so this would probably break a number of (at least my) unit tests if (2) were chosen. Robert Landers Software Engineer Utrecht NL --- ## #121407 — Larry Garfield — 2023-10-18T16:32:36+00:00 URL: https://externals.io/message/121356#121407 · In reply to: #121384 > > > […] > > Hello, > > > […] > > How would someone make an anonymous class "unfinal"? I've used this > "hack" in unit tests, many times. It's quite useful, so this would > probably break a number of (at least my) unit tests if (2) were > chosen. Making anon classes final by default would necessitate a new keyword to de-final them; `open` comes to mind as that's what Kotlin uses for that purpose, but there are other options to bikeshed. I... don't even know how to extend an anon class, honestly, so I'm pretty sure the impact of going all the way would be small. I'm currently undecided on which I prefer, but at least allowing them to be final sounds reasonable. One thing I'm not sure about: What opcache optimizations would final enable? --Larry Garfield --- ## #121562 — daniil@daniil.it — 2023-11-02T23:18:48+00:00 URL: https://externals.io/message/121356#121562 · In reply to: #121407 Hi, > One thing I'm not sure about: What opcache optimizations would final enable?  Well for example, any JIT logic gated behind a check on ZEND_ACC_FINAL: https://github.com/php/php-src/blob/master/ext/opcache/jit/zend_jit_trace.c#L4507 Regards, Daniil Gentili --- ## #121681 — Daniil Gentili — 2023-11-15T17:41:43+00:00 URL: https://externals.io/message/121356#121681 · In reply to: #121356 Hi all, I've created the RFC, I'd be more than glad to receive feedback: https://wiki.php.net/rfc/final_anonymous_classes Thanks, Daniil Gentili. --- ## #121682 — tim@bastelstu.be — 2023-11-15T19:03:32+00:00 URL: https://externals.io/message/121356#121682 · In reply to: #121681 Hi > I've created the RFC, I'd be more than glad to receive feedback: > https://wiki.php.net/rfc/final_anonymous_classes > The official start of the discussion period should likely be announced in a separate thread that also contains the "RFC" keyword within the Subject, otherwise it might be missed. Regarding the RFC itself, I find the voting options unclear. It says that they are mutually exclusive, but it doesn't say what happens when multiple are accepted. Personally I can see myself voting for both "Option 1" and "Option 2", because I believe it is useful if users would be able to make them final for consistency, but I would find it even more useful if they would all be final by default, but would not find it useful to introduce a new 'open' keyword. Some other folks might want to see all anon classes final by default, but don't care about whether there is the escape hatch or not and thus would vote for all 3 options. (I'm happy to repeat that above paragraph in the new thread, once you create it, but this gives you some time to think about it already) Best regards Tim Düsterhus --- ## #121683 — tim@bastelstu.be — 2023-11-15T19:07:49+00:00 URL: https://externals.io/message/121356#121683 · In reply to: #121682 Hi > > > […] > > The official start of the discussion period should likely be announced > in a separate thread that also contains the "RFC" keyword within the > Subject, otherwise it might be missed. And one more note, it appears that neither of your two RFCs are listed on the overview page at: https://wiki.php.net/rfc Best regards Tim Düsterhus --- ## #121686 — Daniil Gentili — 2023-11-15T19:47:31+00:00 URL: https://externals.io/message/121356#121686 · In reply to: #121682 Hi, > Regarding the RFC itself, I find the voting options unclear. It says > that they are mutually exclusive, but it doesn't say what happens when > multiple are accepted. Personally I can see myself voting for both > "Option 1" and "Option 2", because I believe it is useful if users > would be able to make them final for consistency, but I would find it > even more useful if they would all be final by default, but would not > find it useful to introduce a new 'open' keyword. Some other folks > might want to see all anon classes final by default, but don't care > about whether there is the escape hatch or not and thus would vote for > all 3 options. > Thanks for all the tips, did everything (I did indeed forget to add the rfc to the main page, thanks for reminding me!). Regarding the voting options, all three options are mutually exclusive, but since some people (myself included) may be OK with more than one of the following options and may vote in favor of more than one option, I would propose a tie-breaker second vote in case more than one of the options finish with the same number of favorable votes. In this second, eventual tie-breaker vote, voting favorably for only one of the options would be allowed. Regards, Daniil Gentili.