On Mon, 16 Jan 2023, Max Kellermann wrote:

> On 2023/01/16 13:38, Kamil Tekiela <tekiela...@gmail.com> wrote:
> 
> > 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.

Including a "random" zend header also sounds like a great benefit. I 
shouldn't need to care as an extension author which header enables which 
internal function(s) for usage.
 
> 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.

This is a very naive view of the world. You don't get to decide what is 
"good for other people".

> > Do you see any downsides to your new approach?
> 
…
> 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.

When looking at the commit history, I saw more than a dozen commits 
doing a small change. That is clutter.

Adding forwards declarations for zend_* structs, is clutter.

Adding comments that go out of date as to why a header is included is 
also clutter.

> Dmitry Stogov said it's "just a useless permutation", but I can't 
> understand this argument either.

It creates code-churn, which makes merging up fixes from older branches 
harder. 

cheers,
Derick
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to