On 2023/01/20 10:53, Jakub Zelenka <bu...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
