Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119276 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 49469 invoked from network); 16 Jan 2023 12:54:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jan 2023 12:54:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 962411804D4 for ; Mon, 16 Jan 2023 04:54:02 -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=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 138.201.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from swift.blarg.de (swift.blarg.de [138.201.185.127]) by php-smtp4.php.net (Postfix) with ESMTP for ; Mon, 16 Jan 2023 04:54:01 -0800 (PST) Received: from swift.blarg.de (swift.blarg.de [IPv6:2a01:4f8:c17:52a8::2]) (Authenticated sender: max) by swift.blarg.de (Postfix) with ESMTPSA id E79F940FB1; Mon, 16 Jan 2023 13:54:00 +0100 (CET) Date: Mon, 16 Jan 2023 13:53:59 +0100 To: Kamil Tekiela Cc: internals@lists.php.net Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [PHP-DEV] RFC: rules for #include directives From: max+php@blarg.de (Max Kellermann) On 2023/01/16 13:38, Kamil Tekiela wrote: > Did you create an RFC already? Or is this RFC-like discussion? No. I followed https://wiki.php.net/rfc/howto and this is step 1. Creating the actual RFC is step 3. (I'm new to PHP and this process - so far, I've only contributed PHP code through GitHub, and I was surprised by today's sudden resistance against my code cleanup by two PHP developers, after the others welcomed by changes.) > In either case, if you are asking community to come to a decision, we need > to see some background. > Why do you want to change this? What's the benefit? For cleaner code, more readable code (less obscurity in huge amounts of undocumented #includes), more correct code, less fragile code, reduced compile times. > What's the impact on other maintainers, especially extension > maintainers? Other maintainers may need to determine which includes they really need, instead of relying on everything always already there by including one random zend_* header. Extension maintainers may see build failures because, for example, they forgot to include errno.h but used "errno". This previously worked because all PHP headers included errno.h even though there was no reason to. These build failures are bugs in those extensions, and revealing them is a good thing, even though it seems tedious at first. > Do you see any downsides to your new approach? Like any code cleanup, this can result in regressions for parts of PHP that are not covered by a test and not built with the CI, like the DTrace regression yesterday. And code cleanups can easily reveal existing bugs, which is a good thing, but those bugs can be hidden at first - e.g. failure to explicitly include "php_config.h" will (silently) disable features and break things. That may cause some temporary pain, but in the end will result in better code, though some will believe that it isn't a worthy goal or not worth the temporary pain. Derick Rethans wrote my idea "adds nothing but clutter", but I guess he should explain what bothers him; I don't comprehend this, because from my perspective, I intend to remove clutter. Dmitry Stogov said it's "just a useless permutation", but I can't understand this argument either. Max