Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121933
Message-ID: <a83ddbdd-2cd5-4c1a-9942-d5ecb5d4ee17@gmail.com>
Date: Tue, 5 Dec 2023 19:31:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: internals@lists.php.net
References: <b9857726-4037-47e4-9407-41b9262af9fc@gmail.com>
Content-Language: en-US
In-Reply-To: <b9857726-4037-47e4-9407-41b9262af9fc@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [VOTE] [RFC] Final anonymous classes
From: daniil.gentili@gmail.com (Daniil Gentili)

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,

 >>> 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

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.