Hi
On 2/1/23 13:13, Max Kellermann wrote:
On 2023/01/30 11:26, Max Kellermann <max+...@blarg.de> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
