Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121917
Return-Path: <andreas@heigl.org>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 18351 invoked from network); 3 Dec 2023 18:47:48 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 3 Dec 2023 18:47:48 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id DBE99180038
	for <internals@lists.php.net>; Sun,  3 Dec 2023 10:47:56 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,SPF_HELO_NONE,
	SPF_PASS autolearn=no autolearn_force=no version=4.0.0
X-Spam-Virus: No
X-Envelope-From: <andreas@heigl.org>
Received: from mail.stella-maris.solutions (mail.stella-maris.solutions [46.101.232.159])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Sun,  3 Dec 2023 10:47:56 -0800 (PST)
Received: from [192.168.2.95] (heigl.gw.tgnet.de [80.72.250.242])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.stella-maris.solutions (Postfix) with ESMTPSA id 209D07E004;
	Sun,  3 Dec 2023 18:47:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=heigl.org; s=mail;
	t=1701629263; bh=gHbJkE0wuE8o5RMr6oTB25hZUhRAcjeWkgaHvfalaC4=;
	h=Date:Subject:To:References:From:In-Reply-To:From;
	b=A4ZUGmbMB5BdCiMu/j9RgsZp6fxEkN6usYb2U2Yted79CeiemtRMhy+lMjrkHSBIO
	 0E2ORb1kiPNzhbiCjKigPjnwUafZG5q5wGHD/GI0KbTs+0WMP80teQqLIp6lpzn5Qk
	 UkPpswqlo4+XpXc4HC42vRv2Ua7MoxMyH3lbchxhelN6AjpgSgEdNd+/QNNmJ+k/qJ
	 W42reHnvVzQBSMHG0uF2pybYoJQmUxKhgFS4SfPB4lB5P0JGRIWcC5jSRoZ+R33FVq
	 QtM+0IIs8KyKPTZY4LkK8QiwnGzsU7D7/gBVoMp7nhiW9wjxuRBCmcsxP6CSfoxy+F
	 1wZ3PrL3xoaQA==
Message-ID: <2e3d28c5-a3d5-4e8e-b39a-a594bd485ba4@heigl.org>
Date: Sun, 3 Dec 2023 19:47:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <b9857726-4037-47e4-9407-41b9262af9fc@gmail.com>
 <74dcffb7-e8c1-45c8-ae41-9fc0f050f484@app.fastmail.com>
 <92012D5D-B917-46E1-A1A0-6F92404347B0@php.net>
 <b2452719-8ca5-4605-9fa7-18a5f2bd9552@app.fastmail.com>
In-Reply-To: <b2452719-8ca5-4605-9fa7-18a5f2bd9552@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
From: andreas@heigl.org (Andreas Heigl)

Am 03.12.23 um 19:34 schrieb Larry Garfield:
> On Sun, Dec 3, 2023, at 10:34 AM, Derick Rethans wrote:
>> On 3 December 2023 14:49:12 GMT, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>> On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote:
>>>> Hi all,
>>>>
>>>> I've just opened voting for the final anonymous classes RFC @
>>>> https://wiki.php.net/rfc/final_anonymous_classes.
>>>>
>>>> Voting started now, and will run until December 18th 2023, 00:00 GMT.
>>>
>>> For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final.
>>>
>>> It makes very little sense to me that everyone needs to explicitly mark their anonymous classes as final just because there is a class_alias loophole that could, in theory, have been used to extend anonymous classes in the past. Especially given that there is no evidence of this "feature" being used in the wild (or if there is such evidence, it was not presented in the proposal).
>>>
>>> Regards,
>>> Nikita
>> I agree with this, and would also say that this RFC is the most thin
>> one I've seen.
>>
>> There is no reasoning, or examples, or pretty much anything else in it.
> 
> I have also voted no for the same reasons as above.  A more fleshed out RFC that goes default-final (which would then enable the engine optimizations mentioned) I would probably vote yes for.  Though one could debate if that should be saved for 9.0 just to be safe.  (Which I'd also be fine with.)

I also voted NO for the same reason.

But also because I am missing a few things in the RFC.

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? 
(Apart from not being able to write `new final class{}`)

Also I'd expect all the relevant information from the discussion to be 
in the RFC so that we can figure out what the main points were without 
having to dig through Mailinglists or PRs.

Cheers

Andreas
-- 
                                                               ,,,
                                                              (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                      https://hei.gl/where |
|                                        https://hei.gl/pubkeyandreas |
+---------------------------------------------------------------------+