On Wed, Oct 18, 2023, at 12:35 PM, Robert Landers wrote: > On Wed, Oct 18, 2023 at 2:26 PM Tim Düsterhus <t...@bastelstu.be> wrote: >> >> Hi >> >> On 10/17/23 19:06, Daniil Gentili wrote: >> > 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. >> > > > 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.
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
