Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119363
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_97b3e0639c9bb1fc6b609e7e5411c059"
Date: Fri, 20 Jan 2023 11:51:23 +0100
To: Max Kellermann <max+php@blarg.de>
Cc: internals@lists.php.net
In-Reply-To: <Y8pqSmpz4hUFY72u@swift.blarg.de>
References: <Y8U9B4AVP/R7vazI@swift.blarg.de> <CAFPFaM+FpJj0=Urdz-JUihtNENC_DbG+cKbwwiVNg4GNvZrdZA@mail.gmail.com>
 <Y8e1VLXmnZP66dSg@swift.blarg.de> <CAFPFaMJPt7ZfvfYmoWPGCfDuNW1tLPKwpxHaoy5+k3-RRaXovA@mail.gmail.com>
 <Y8fe2DQqcB7uJhK8@swift.blarg.de> <192ba7b6-dcf0-e2da-c99e-cbad40519e27@gmx.de>
 <Y8gIW3x3KLvrj/H7@swift.blarg.de> <CAEKnhAFmznONstO4Lbb=5C6sieM=ZpAD_EzpSf75AmgEFmpHiA@mail.gmail.com>
 <Y8pqSmpz4hUFY72u@swift.blarg.de>
Message-ID: <d854c80645b280e0ea16f6702c085bc7c52ae0dd0b2c1ca63b74563d4c60188e@mahalux.com>
Subject: Re: [PHP-DEV] RFC: rules for #include directives
From: vorismi3@fjfi.cvut.cz (=?UTF-8?Q?Michael_Vo=C5=99=C3=AD=C5=A1ek_-_=C4=8CVUT_FJFI?=)

--=_97b3e0639c9bb1fc6b609e7e5411c059
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8; format=flowed

> comments like #include "zend_execute.h" // for zend_vm_calc_used_stack()

Maintaining "the correct" includes manually is hard. Maintaining the
comments manually is even harder. 

In
https://github.com/php/php-src/blob/a3a3f326bd32005dd68936edf0e01f98a2fbe163/CODING_STANDARDS.md?plain=1#L269
you proposed a tool to determine the needed includes. 

I would highly appreciate if this could be done automatically, ie.
generate "the correct" includes and assert them by
https://github.com/php/php-src/blob/php-8.2.1/.github/actions/verify-generated-files/action.yml
CI. If you can generate the comments too, they can be asserted by CI
reliably then as well. 

With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

On 20 Jan 2023 11:17, Max Kellermann wrote:

> On 2023/01/20 10:53, Jakub Zelenka <bukka@php.net> wrote: 
> 
>> I'm afraid it's too late for PHP.
> 
> It's never too late.  Don't give up PHP :-)
> 
> PHP is an old code base.  I want to help modernize it.
> 
>> As it was said, this is problematic for bug fixes when merging up
>> and it's extra hurdle for maintainers - read this will slow down the
>> development.
> 
> Can I do anything to help with those merges?
> 
>> Also this is not something I would like to see in a minor version bump even
>> though we can break ABI in that version but in general we try to introduce
>> as little changes as possible for extensions. If anything it should at
>> least wait for the next major version bump when extension devs expect more
>> work to be done.
> 
> What about: let's branch PHP 8.3 out, and declare master will become
> 9.0.  (Or create a new branch for 9.0 and let 8.3 stay in master;
> branches names doesn't matter, only the idea matters.)
> 
> I volunteer to do regular (daily?) merges from the 8.3 branch to the
> 9.0 branch, and fix all the problems that may occur.
> 
>> I think comments are more useful in the actual header to explain
>> what it is for which can be done in a few lines. It can be more
>> detailed and doesn't need to be repeated...
> 
> I agree with that part.  More documentation for headers is useful.
> 
> As I said in another reply, I feel those comments are only really
> useful for those large and obscure catch-all headers such as
> "zend_types.h".  Check my "zend_result.h" commit - it makes lots of my
> comments disappear, because suddenly the #include directive becomes
> self-explaining.
> 
>> - some of the removed headers from libc should be kept as there's
>> just a small benefit in removing them (e.g. errno.h)
> 
> There is a benefit in removing them; improved compile times and
> reduced namespace pollution (which is a theoretical benefit which is
> probably not valued by all).
> 
> But the benefit of keeping it is only source compatibility with buggy
> extensions.
> 
> And source compatibility with buggy extensions can be had by moving
> those #include directives to "php_compat.h", with a way for "good"
> extensions to opt out of the bloat.
> 
> If you believe source compatibility even with "bad" extensions is
> utterly important, I'll consider that in my submissions, and will
> consider all build breakages as regressions that need to be fixed in
> PHP (e.g. php_compat.h).  I don't have a real opinion on that, I'll
> accept whatever you decide and will help implement it.
> 
> Max
--=_97b3e0639c9bb1fc6b609e7e5411c059--