rfc:final_anonymous_classes

This is an old revision of the document!


PHP RFC: Final anonymous classes

Introduction

This RFC proposes to add support for final anonymous classes.

Proposal

This RFC proposes to add support for final anonymous classes.

This should also allow some additional opcache optimizations, such as any JIT logic gated behind a check on ZEND_ACC_FINAL, i.e. https://github.com/php/php-src/blob/master/ext/opcache/jit/zend_jit_trace.c#L4507.

Backward Incompatible Changes

None.

Proposed PHP Version(s)

Next PHP 8.4

RFC Impact

See Backward Incompatible Changes.

Proposed Voting Choices

2/3 required to accept. Voting started on 2023-12-03 and will end on 2023-12-18 00:00 GMT.

Add support for final anonymous classes?
Real name Yes No
alcaeus (alcaeus)  
alec (alec)  
ashnazg (ashnazg)  
brzuchal (brzuchal)  
crell (crell)  
cschneid (cschneid)  
derick (derick)  
devnexen (devnexen)  
dharman (dharman)  
galvao (galvao)  
geekcom (geekcom)  
heiglandreas (heiglandreas)  
kalle (kalle)  
kguest (kguest)  
levim (levim)  
mbeccati (mbeccati)  
nicolasgrekas (nicolasgrekas)  
nielsdos (nielsdos)  
nikic (nikic)  
ocramius (ocramius)  
ramsey (ramsey)  
sebastian (sebastian)  
stas (stas)  
weierophinney (weierophinney)  
Final result: 8 16
This poll has been closed.

Patches and Tests

Final anonymous classes implementation: https://github.com/php/php-src/pull/11126

References

Rejected Features

After feedback received from Nikolas Grekas in the last [RFC] discussion thread (https://externals.io/message/121685), I moved here a large chunk of the rationale and removed basically all the alternative polls I had initially planned to propose:

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't be proposed unless absolutely needed IMHO.

Nicolas

What follows is the text of the original 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.

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.

Thus, this RFC initially included three mutually exclusive proposals:

  1. Add support for final anonymous classes (new final class {} syntax, no breaking changes)
  2. OR Make all anonymous classes final by default, without the option to make them final (breaking change)
  3. OR Make all anonymous classes final by default, provide an optional open keyword to make them non-final (like in Kotlin, new open class {}, breaking changes).

As an extra proposal related to the last two options, possibly requiring a separate RFC, in the last two cases, it might be a good idea to also disallow the use of class_alias altogether for final anonymous classes (suggested by nikolas-grekas in https://github.com/php/php-src/pull/11126#issuecomment-1522042841).

rfc/final_anonymous_classes.1701799881.txt.gz · Last modified: 2023/12/05 18:11 by danog