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.
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
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?
- Allow the 'final' keyword on anonymous classes?
- Enforce that all anonymous classes are final?
Best regards
Tim Düsterhus
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.
Hello,
Perhaps make it two votes, each requiring a 2/3 majority?
- Allow the 'final' keyword on anonymous classes?
- 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
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.Hello,
Perhaps make it two votes, each requiring a 2/3 majority?
- Allow the 'final' keyword on anonymous classes?
- 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
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
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.
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
Hi
I've created the RFC, I'd be more than glad to receive feedback:
https://wiki.php.net/rfc/final_anonymous_classesThe 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:
Best regards
Tim Düsterhus
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.