Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119362
Date: Fri, 20 Jan 2023 11:17:46 +0100
To: Jakub Zelenka <bukka@php.net>
Cc: internals@lists.php.net
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEKnhAFmznONstO4Lbb=5C6sieM=ZpAD_EzpSf75AmgEFmpHiA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: rules for #include directives
From: max+php@blarg.de (Max Kellermann)

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