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 <[email protected]> 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
