Everything

php

Final anonymous classes

php.internals

Daniil Gentili

2 years ago

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.

Saki Takamachi

2 years ago

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

Tim Düsterhus

2 years ago

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.
>

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

Robert Landers

2 years ago

On Wed, Oct 18, 2023 at 2:26 PM Tim Düsterhus <tim@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.

Robert Landers
Software Engineer
Utrecht NL

Larry Garfield

2 years ago

On Wed, Oct 18, 2023, at 12:35 PM, Robert Landers wrote:

> On Wed, Oct 18, 2023 at 2:26 PM Tim Düsterhus <tim@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

Daniil Gentili

2 years ago

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

Daniil Gentili

2 years ago

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.

Tim Düsterhus

2 years ago

Hi

On 11/15/23 18:41, Daniil Gentili wrote:

> 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

Tim Düsterhus

2 years ago

Hi

On 11/15/23 20:03, Tim Düsterhus wrote:

> On 11/15/23 18:41, Daniil Gentili wrote:
>> 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.

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

Daniil Gentili

2 years ago

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.