Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119282
MIME-Version: 1.0
References: <Y8U9B4AVP/R7vazI@swift.blarg.de> <CAGBsUrdQAXE2qk_UDQY9v6pYpWH+=bX6S3ou+sttQamtDC1F9A@mail.gmail.com>
 <Y8VI5yanzli8D4Cm@swift.blarg.de>
In-Reply-To: <Y8VI5yanzli8D4Cm@swift.blarg.de>
Date: Mon, 16 Jan 2023 11:14:39 -0500
Message-ID: <CAPKYkKyea-BFg94nyh-DHNLZuwQrEuJ2HR4D8kYKktfsj=f8sQ@mail.gmail.com>
To: Max Kellermann <max+php@blarg.de>
Cc: Kamil Tekiela <tekiela246@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000008635a05f263e2b7"
Subject: Re: [PHP-DEV] RFC: rules for #include directives
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000008635a05f263e2b7
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 16, 2023 at 7:54 AM Max Kellermann <max+php@blarg.de> wrote:

> On 2023/01/16 13:38, Kamil Tekiela <tekiela246@gmail.com> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
For those of us that don't know the finer details of the build process,
will that have any impact on the final product such as reduced binary sizes
or better performance? I'm not saying that code cleanup isn't a good enough
reason to do this on its own, just curious if there are other advantages
beyond that.
-- 
Chase Peeler
chasepeeler@gmail.com

--00000000000008635a05f263e2b7--