Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121686 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 92475 invoked from network); 15 Nov 2023 19:47:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Nov 2023 19:47:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 92C8A180087 for ; Wed, 15 Nov 2023 11:47:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-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,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS2639 136.143.188.0/23 X-Spam-Virus: No X-Envelope-From: Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com [136.143.188.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 15 Nov 2023 11:47:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700077658; cv=none; d=zohomail.com; s=zohoarc; b=OxPDckfvmeM3RAZ1APplrF38K+ThRY0vTrBhVAyCY/2LX7mfNumQer0NYkrNC2BfjdL2qJfm6zGCmcKXLtr0gb/sJPC5JdyuhlsrWvQFwRsu2LErrZqIA+tPe3wXgLU9svFsS7hNEfr5CrkppGOZORKt58884plR/8IiMd9Wn40= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1700077658; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=wuX02TmDpA6Zxcy9uwNOtPJPa7aDLOli984pHYL53xs=; b=j1+7HRqe8B6xrKfNS+sFgicNoWpmnNDQXdL0NoWfByM2Hyc+4yD+1M/uJxjT6x5yPhftFLL3BALrNQ7OhgEKXDMXqrG1MIKmSk6hTFeNvI7OTjieJRH3SSnldLKejwBfMerQUWc1rKpCqSwVLlCzh3JhZhXv31lupNfBf4FUIOA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=daniil.it; spf=pass smtp.mailfrom=daniil@daniil.it; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1700077658; s=daniil; d=daniil.it; i=daniil@daniil.it; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=wuX02TmDpA6Zxcy9uwNOtPJPa7aDLOli984pHYL53xs=; b=VJK7WkdvHxp462AaBSm+opTLGrrFwx+RvhumONhAoLG7isot9NBMZAdPZXeo2zG4 X9xzwO/8eUq0nMwV51n4ViVNqv6IgNHthJ5ucdQ+p5CVxLxXcJ07Yirn5poBfH/TLAp fEflzIUT5LckL3zBwhC/KLH6UaSTpTz2SJPo2CHc= Received: from [192.168.69.130] (128.116.205.77 [128.116.205.77]) by mx.zohomail.com with SMTPS id 1700077657288999.3298128225501; Wed, 15 Nov 2023 11:47:37 -0800 (PST) Message-ID: <23298b18-84aa-4aaa-9099-3049d7ba81df@daniil.it> Date: Wed, 15 Nov 2023 20:47:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= , internals@lists.php.net References: <1962ad66-26ed-4ebd-8e64-0f3bd3d4ba9b@bastelstu.be> In-Reply-To: <1962ad66-26ed-4ebd-8e64-0f3bd3d4ba9b@bastelstu.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External Subject: Re: [PHP-DEV] Re: Final anonymous classes From: daniil@daniil.it (Daniil Gentili) 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.