Re: [PHP-DEV] Final anonymous classes

2023-11-02 Thread daniil
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


Re: [PHP-DEV] Final anonymous classes

2023-10-18 Thread Larry Garfield
On Wed, Oct 18, 2023, at 12:35 PM, Robert Landers wrote:
> On Wed, Oct 18, 2023 at 2:26 PM Tim Düsterhus  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



Re: [PHP-DEV] Final anonymous classes

2023-10-18 Thread Robert Landers
On Wed, Oct 18, 2023 at 2:26 PM Tim Düsterhus  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-10-18 Thread Tim Düsterhus

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-10-17 Thread Saki Takamachi
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



[PHP-DEV] Final anonymous classes

2023-10-17 Thread Daniil Gentili

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.


Re: [PHP-DEV] Final anonymous classes

2023-05-06 Thread Larry Garfield
On Sat, May 6, 2023, at 2:16 AM, Rokas Šleinius wrote:
> On Fri, 5 May 2023 at 23:58, Levi Morrison via internals
>  wrote:
>>
>> I am not sure about making them final by default. I think it's a more
>> consistent language design to allow `new final class()` as you
>> originally proposed. Although I don't know why anyone would want to
>> extend anonymous classes, we can see that people do, in fact, do it. I
>> don't see why we couldn't allow `new class() extends $someClass` in
>> the future to specifically allow them to do this. I mean, I'm not
>> going to lobby for it, I'm just pointing out that is more aligned and
>> consistent with other parts of the language, than to simply make it
>> final by default.
>>
>> Cheers.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>
> My work currently is integrating with various shipping provider APIs
> such as DHL. I have to deal with the enormous API request (and
> response) definitions. I am just creating a DTO class for each level
> of JSON key, which results in a HUGE amount of classes.
>
> I have a hunch this problem can be solved better with anonymous
> classes, but their support is not great yet - PHPStorm has a breaking
> bug with their autocompletion and I am too dumb to figure out a better
> solution in any case.

I think you're on the right track with named classes, honestly.  With current 
PHP versions that's syntactically a lot nicer than it used to be.

> However, I totally agree with Levi in that the way forward is better
> towards `new class() extends $someClass` and not "all anonymous
> classes final by default". It may open patterns and opportunities we
> have yet to think about.

My understanding of the engine implementation is that extending from a class 
dynamically would be really really hard.  (Anon classes are not defined at 
runtime, they get defined at compile time, just with an auto-generated name.)  
That said, I have to agree here as well that I'm not a fan of forcing anon 
classes to be final, but if someone could figure out dynamic-extension anon 
classes, I would be a happy camper.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-05-06 Thread Rokas Šleinius
On Fri, 5 May 2023 at 23:58, Levi Morrison via internals
 wrote:
>
> I am not sure about making them final by default. I think it's a more
> consistent language design to allow `new final class()` as you
> originally proposed. Although I don't know why anyone would want to
> extend anonymous classes, we can see that people do, in fact, do it. I
> don't see why we couldn't allow `new class() extends $someClass` in
> the future to specifically allow them to do this. I mean, I'm not
> going to lobby for it, I'm just pointing out that is more aligned and
> consistent with other parts of the language, than to simply make it
> final by default.
>
> Cheers.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

My work currently is integrating with various shipping provider APIs
such as DHL. I have to deal with the enormous API request (and
response) definitions. I am just creating a DTO class for each level
of JSON key, which results in a HUGE amount of classes.

I have a hunch this problem can be solved better with anonymous
classes, but their support is not great yet - PHPStorm has a breaking
bug with their autocompletion and I am too dumb to figure out a better
solution in any case.

However, I totally agree with Levi in that the way forward is better
towards `new class() extends $someClass` and not "all anonymous
classes final by default". It may open patterns and opportunities we
have yet to think about.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-05-05 Thread Levi Morrison via internals
I am not sure about making them final by default. I think it's a more
consistent language design to allow `new final class()` as you
originally proposed. Although I don't know why anyone would want to
extend anonymous classes, we can see that people do, in fact, do it. I
don't see why we couldn't allow `new class() extends $someClass` in
the future to specifically allow them to do this. I mean, I'm not
going to lobby for it, I'm just pointing out that is more aligned and
consistent with other parts of the language, than to simply make it
final by default.

Cheers.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-05-05 Thread Derick Rethans
On Mon, 24 Apr 2023, Daniil Gentili wrote:

> I've submitted https://github.com/php/php-src/pull/11126 to add 
> support for final anonymous classes, though as noted by iluuu1994, it 
> would probably make more sense to just make all anonymous classes 
> final by default, what do you think?

Yes.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-04-25 Thread Juliette Reinders Folmer

On 24-4-2023 12:28, Daniil Gentili wrote:

Hi all,

I've submitted https://github.com/php/php-src/pull/11126 to add 
support for final anonymous classes, though as noted by iluuu1994, it 
would probably make more sense to just make all anonymous classes 
final by default, what do you think?


Daniil Gentili.



I always though anonymous class where `final` by nature. The fact that 
that hack to extend them works, seems iffy at best.


For what it's worth, I'd be in favour of making the default behaviour 
for anonymous classes `final` without the need to add a `final` keyword.


For those edge-cases which would be broken by that change, I wonder if 
support to opt-out could be added via an `#[AllowAliasing]` attribute ?


Re: [PHP-DEV] Final anonymous classes

2023-04-25 Thread Claude Pache



> Le 25 avr. 2023 à 15:46, Nicolas Grekas  a 
> écrit :
> 
> 
> Because they conceptually don't create a new type, I wonder if (final)
> anonymous classes could be allowed to extend final classes? In order to not
> allow hacking around and still create a type with class_alias(), we should
> forbid aliasing final anonymous classes IMHO. Then we could have this
> discussion about allowing finally anonymous classes to extend final
> classes. That'd be really useful in many situations where "final" is
> preventing end users from achieving what they want.


That would violate the very definition of `final`, which may be interpreted as 
“final implementation” as much as “final type”?

If your goal is to have a proxy, I wonder whether it would be more appropriate 
to design a proper way to define a proxy around an existing object, rather than 
hacking around class inheritance?


—Claude 
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-04-25 Thread Larry Garfield
On Tue, Apr 25, 2023, at 1:21 PM, Ilija Tovilo wrote:
> Hi Claude
>
>> > Hi all,
>> >
>> > I've submitted https://github.com/php/php-src/pull/11126 to add support 
>> > for final anonymous classes, though as noted by iluuu1994, it would 
>> > probably make more sense to just make all anonymous classes final by 
>> > default, what do you think?
>>
>> Extending an anonymous class is indeed possible (https://3v4l.org/pDFTL), 
>> but it is a hack as best. If someone wants a non-final class, could they not 
>> write a non-anonymous one? As a bonus, they wouldn’t need to instantiate the 
>> class before referencing it.
>
> Indeed. The argument was that, if you need to give the anonymous class
> a dedicated name through an alias to extend it, you might as well
> declare a named class in the first place.
>
> In case somebody finds benefit in making anonymous classes open, it
> seems more sensible to make them opt into openness, rather than
> applying this behavior to all anonymous classes that are used as final
> 99.9% of the time. Although I really don't think that is necessary.
>
> Ilija

I agree, but that would then require adding some kind of "non-final" keyword 
for anon classes to opt back out of finalness.  That's an extra complication I 
don't see as worth the effort to think through.

Until this thread it hadn't even occurred to me that you could extend an anon 
class at all, so the issue never came up.  And the apparent way to do so 
involves eval(), so I'm already afraid of it.  Given how edge-casey this is, 
I'd be inclined to just leave it be.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-04-25 Thread Nicolas Grekas
Hi all,

> > I've submitted https://github.com/php/php-src/pull/11126 to add support
> for final anonymous classes, though as noted by iluuu1994, it would
> probably make more sense to just make all anonymous classes final by
> default, what do you think?
> >
> > Extending an anonymous class is indeed possible (https://3v4l.org/pDFTL),
> but it is a hack as best. If someone wants a non-final class, could they
> not write a non-anonymous one? As a bonus, they wouldn’t need to
> instantiate the class before referencing it.
>
> Indeed. The argument was that, if you need to give the anonymous class
> a dedicated name through an alias to extend it, you might as well
> declare a named class in the first place.
>
> In case somebody finds benefit in making anonymous classes open, it
> seems more sensible to make them opt into openness, rather than
> applying this behavior to all anonymous classes that are used as final
> 99.9% of the time. Although I really don't think that is necessary.
>

Fun fact: I wrote test code that extends anonymous classes recently.
The typical test case is like this:

$obj = new class() {
public array $foo;
};
$proxy = $this->createLazyGhost($obj::class, fn () => null);


And createLazyGhost() generates a proxy class and returns an instance of
it, see
https://github.com/symfony/symfony/blob/1f8c5928a1445378eacbaf5b7e1636fdfa8610ed/src/Symfony/Component/VarExporter/Tests/LazyGhostTraitTest.php#L415-L438

Admittedly this is for convenience in writing test cases, but convenience
is what many RFCs are about :)

But anyway, there is a related idea I've had in my mind about anonymous
classes that I'd like to throw in that conversation:

Because they conceptually don't create a new type, I wonder if (final)
anonymous classes could be allowed to extend final classes? In order to not
allow hacking around and still create a type with class_alias(), we should
forbid aliasing final anonymous classes IMHO. Then we could have this
discussion about allowing finally anonymous classes to extend final
classes. That'd be really useful in many situations where "final" is
preventing end users from achieving what they want.

Nicolas


Re: [PHP-DEV] Final anonymous classes

2023-04-25 Thread Ilija Tovilo
Hi Claude

> > Hi all,
> >
> > I've submitted https://github.com/php/php-src/pull/11126 to add support for 
> > final anonymous classes, though as noted by iluuu1994, it would probably 
> > make more sense to just make all anonymous classes final by default, what 
> > do you think?
>
> Extending an anonymous class is indeed possible (https://3v4l.org/pDFTL), but 
> it is a hack as best. If someone wants a non-final class, could they not 
> write a non-anonymous one? As a bonus, they wouldn’t need to instantiate the 
> class before referencing it.

Indeed. The argument was that, if you need to give the anonymous class
a dedicated name through an alias to extend it, you might as well
declare a named class in the first place.

In case somebody finds benefit in making anonymous classes open, it
seems more sensible to make them opt into openness, rather than
applying this behavior to all anonymous classes that are used as final
99.9% of the time. Although I really don't think that is necessary.

Ilija

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] Final anonymous classes

2023-04-24 Thread Claude Pache


> Le 24 avr. 2023 à 12:28, Daniil Gentili  a écrit :
> 
> Hi all,
> 
> I've submitted https://github.com/php/php-src/pull/11126 to add support for 
> final anonymous classes, though as noted by iluuu1994, it would probably make 
> more sense to just make all anonymous classes final by default, what do you 
> think?
> 
> Daniil Gentili.
> 

Hi,

Extending an anonymous class is indeed possible (https://3v4l.org/pDFTL), but 
it is a hack as best. If someone wants a non-final class, could they not write 
a non-anonymous one? As a bonus, they wouldn’t need to instantiate the class 
before referencing it.

—Claude



[PHP-DEV] Final anonymous classes

2023-04-24 Thread Daniil Gentili

Hi all,

I've submitted https://github.com/php/php-src/pull/11126 to add support 
for final anonymous classes, though as noted by iluuu1994, it would 
probably make more sense to just make all anonymous classes final by 
default, what do you think?


Daniil Gentili.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php