Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119515 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55050 invoked from network); 9 Feb 2023 18:04:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Feb 2023 18:04:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3A011180546 for ; Thu, 9 Feb 2023 10:04:06 -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,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 176.9.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 9 Feb 2023 10:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1675965844; bh=1qyuZ6QuAB8IJcBWLBbXDfAUpYsAoGzIGj9wzLwHBxI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=eOsYXZJfke1ceqQ1A9jZy7yQVc3rLMRpnvwSUn8dLNKrmFvMLFA9RBjewEd+7mGmY GrvxPlRbMBdo1BEimzCvYQrLC9v8hX5X3uWco9CdklDNIpvuqs/I145Wgvld/vO/Pu 8adVzBe+NjpzX4Yxf2T2Iq1XPbDhuCL4q3n/sQyC5BFFExgf9CjC38sMcUAw/ZFMwf yAzO2CrO7vPd4ZddINYWOCD6QmapUK0l1LoDUB7QP6HjaMEPDBx4/K5gZyp0c3XID8 K8tq3LIkBUds7K46ZJzC3oAL4vVTRc4BjQSeoD8octM+vbW78yNcHesU31ygNtHmvo 9CSyImqWfCQeg== Message-ID: <1cb213ea-ff7d-c4b2-5345-fadbc5953c94@bastelstu.be> Date: Thu, 9 Feb 2023 19:04:03 +0100 MIME-Version: 1.0 Content-Language: en-US To: Max Kellermann , internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [VOTE] include cleanup From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=) Hi On 2/1/23 13:13, Max Kellermann wrote: > On 2023/01/30 11:26, Max Kellermann wrote: >> If nobody objects, I'll announce the start of voting on February 1st. > > That's today. > > Voting starts now, please vote on my RFC: > https://wiki.php.net/rfc/include_cleanup > > Original discussion: https://news-web.php.net/php.internals/119272 > Something about the vote as set up has bothered me since voting started and I believe I just realized what it is: I feel like what's being voted on is ambiguous and depending on how the voter interprets it, the vote also violates the voting rules. This is specifically about the first vote titled "Should #include directives be cleaned up?": The vote as it is worded technically does not make a statement on the inverse: If the vote is declined, it *does not* mean that #include directives *may not* be cleaned up. Instead the status quo would be preserved. To my understanding the status quo is "depends on a case-by-case basis", because we do not currently have any guidelines regarding #include. However based on the discussion of the RFC I believe that voters may have assumed that a "No" means "A cleanup is not allowed", because several participants expressed an active aversion to a cleanup during the discussion. As for myself I've certainly had that understanding when casting my vote. This interpretation would be in violation of the voting process, because the status quo would be changed no matter the results of the RFC, but the two options would not be equal: Disallowing a clean-up would require 33% of votes, whereas allowing clean-up would require 66% of votes. The status quo "decide on a case by case basis" would no longer be legal even without a clear agreement. If the results of the RFC are going to be interpreted according to the second possible interpretation, then I believe that to be actively harmful: It would disallow removing #include directives entirely and more generally it would prevent any type of refactoring. I find it only natural to "clean up after myself" when moving stuff around. An example would be PHP 8.2's ext/random where several functions moved into a different extension. Any includes specific to those moved functions would need to stay where they were. As one of the persons listed as a maintainer of ext/random I was also thinking about splitting the 'php_random_uint128_t' implementation into a separate header file to keep php_random.h neat and tidy, because the 128 Bit integer operations are only used for the pcgoneseq128xslrr64 engine. Of course I would've coordinated that change with zeriyoshi as the other listed maintainer. Best regards Tim Düsterhus