Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119361
MIME-Version: 1.0
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>
In-Reply-To: <Y8gIW3x3KLvrj/H7@swift.blarg.de>
Date: Fri, 20 Jan 2023 09:53:01 +0000
Message-ID: <CAEKnhAFmznONstO4Lbb=5C6sieM=ZpAD_EzpSf75AmgEFmpHiA@mail.gmail.com>
To: Max Kellermann <max+php@blarg.de>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008533ff05f2af04d6"
Subject: Re: [PHP-DEV] RFC: rules for #include directives
From: bukka@php.net (Jakub Zelenka)

--0000000000008533ff05f2af04d6
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 18, 2023 at 2:55 PM Max Kellermann <max+php@blarg.de> wrote:

>
> Here's my RFC: https://wiki.php.net/rfc/include_cleanup
>
>
I think that some logic behind this RFC makes sense but I would see it more
like something for a new project. I'm afraid it's too late for PHP. At
least doing that in one big step seems very painful and disturbing for not
that much benefit. 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.

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.

Except that, there are few things that I don't like:
- comments next to inclusion don't have any value especially in the way how
it's done - it just puts few things that are in the header and sometimes
that matches the header name (e.g. smart str...). 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...
- some of the removed headers from libc should be kept as there's just a
small benefit in removing them (e.g. errno.h)

That said I think it makes sense but I think the disadvantages outweigh the
advantages...

Regads

Jakub

--0000000000008533ff05f2af04d6--