[PHP-DEV] garbage in bugs.php.net
Hi! Somebody have put a ton of garbage reports in bugs.php.net under security bugs. Cleaning them up manually is kind of annoying, could somebody with DB access go in and clean them all up? They all have either OS or Summary field set to "1" as far as I can see. Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Saner array_(sum|product)()
Hello internals, If there are no further feedback I intend on opening the vote for this tomorrow. Best regards, George P. Banyard
Re: [PHP-DEV] [VOTE] include cleanup
On Thu, 9 Feb 2023 at 22:09, Matthew Weier O'Phinney < mweierophin...@gmail.com> wrote: > I'm not directly involved in maintenance, but my take on the scenario was > that these were rejected and reverted because they caused breakage, whether > that was in compiling a spare PHP build, or in extensions that were > assuming that using certain headers would slurp in everything they needed. > This breakage was unacceptable without an RFC. I saw chatter from a number > of folks after the changes were merged about builds no longer compiling; > considering the stability of the php-src tree, inability to build will > always be a source of alarm. > > [...] > > As I pointed out earlier, the changes previously merged led to breakages > when compiling the project. How is that not enough? And dumping a huge > bunch of PRs with such changes without first discussing it with maintainers > means a lot of effort reviewing [...]. > The other point that has been brought up multiple times is that it > introduces breaking changes for extension maintainers. > > Should these extensions be relying on one or more "god" headers instead of > the specific headers for the symbols they use? Probably not. Will forcing > the issue without giving them a chance to review and understand the > changes, and have a roadmap for when and how those changes occur be a net > positive? No; it will cause a lot of busy work for a lot of people, almost > all of whom are volunteers and most of whom would rather be building out > user-requested features or fixing user-reported bugs. > > I'm unsure why that's unclear or not enough for you. > > -- > Matthew Weier O'Phinney > mweierophin...@gmail.com > https://mwop.net/ > he/him > I'm going to ignore Max's subpar behaviour and frustration in the aftermath of this. However, as the reviewer of these PRs, they did NOT completely break the build, I was working on php-src and compiling master without ANY issues during the weekend after landing the changes. The *only* build being broken was the DTrace build, which would have been fixed by a follow-up PR. We have had completely broken builds for longer days due to some other random changes, and we didn't revert them but fixed them as a follow-up. We still, for over 6 months now, have a "broken" ASAN build due to phpdbg messing up the analyser and crashing the test runner on 8.2 and master, something that multiple core devs, me included, need to work around by monkey patching the run-test.php file. These changes were initially agreed upon and multiple people were in favour, even by Dmitry. I will also say, that I spend a significant amount of time reviewing those PRs, and I would have continued, as I think they are beneficial to the project. But my opinion and the work I put into the reviews is apparently worthless. Therefore, I maintain that, IMHO, these commits should not have been reverted. The unique complaint, that should be addressed to me, is in how I merged the PRs in that I didn't squash them. The fact external extensions were broken and that we should add all relevant headers to php.h is a fair complaint and would have been fixed quite easily in a single commit and did not affect anyone effectively at this stage because we are, checks notes, 6 months at minimum before the first alpha builds of PHP 8.3 are released. The only reason they were reverted is that Dmitry demanded them as they broke the DTrace build, which he is apparently the only one to use and is not tested on CI, a failure of the project's CI infrastructure. As I previously complained, the RFC process for this kind of change is completely inadequate and demonstrates that the PHP project has a massive issue with governance and how to handle cases like this. As a final note, if the complaint had been made by anyone else other than Dmitry, I doubt these changes would have been reverted, and can we please stop pretending otherwise. Sincerely, George P. Banyard
Re: [PHP-DEV] 'Uninitialized' creates a lot of cluttering
On 12 February 2023 11:11:31 GMT, Lydia de Jongh wrote: >The features of a programming-language should not be about preventing >mistakes, imho. What is the point of marking the type of a property, other than to prevent mistakes? >For me it is about the cluttering in an otherwise clean property list. It's only "clutter" if you don't think it conveys useful information, and that's obviously a matter of opinion. >And I think that implicit null on nullable properties could fit nicely >here. For null is a valid value for a nullable. For a type of ?int, null is indeed a valid value; but so is 0, and -1, and so on. Why should the language assume that one default, among all the possibilities, if you don't specify any? Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC karma request
On 12/02/2023 15:46, Thomas Hruska wrote:
> On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:
>> Fwiw I would also find an $offset argument useful. fpassthru's lack of both
>> $length and $offset made my life harder when implementing "HTTP 206 Partial
>> Content" / "HTTP range requests",
>
> I was going to suggest this myself until I realized that an $offset parameter
> would be rather problematic. What happens if the offset is negative? Does a
> negative offset mean seek backwards from the current position OR start at
> that many bytes from the end of the stream? Is the offset a seek operation
> or a read operation? Not all streams are seekable and reading is generally a
> fairly slow, blocking I/O operation. Also, not all stream lengths are known.
> A negative offset in non-seekable scenarios would almost certainly have to
> throw an error. fseek()/fread() are more flexible and consistent for getting
> to the desired starting point in a source stream.
>
A negative offset would not be valid, just like it is not valid for
stream_copy_to_stream.
The offset is a seek operation just like is the case for stream_copy_to_stream.
Not all streams are seekable that's true, but the programmer using the changed
fpassthru function would have the same issue if they were to use fseek or
stream_copy_to_stream.
> A negative $length would also present some issues. Again, not all stream
> lengths are known. Correctly handling negative values would require managing
> an internally, temporarily allocated buffer of sufficient size to be able to
> backtrack streams of unknown length. And might even have to cache the entire
> stream in RAM, which would be problematic for 1GB+ streams. Or just throw an
> error for such streams. Or just restrict $length to non-negative values only.
>
> In short, a non-negative, nullable $length parameter is the only well-defined
> operation for fpassthru().
>
The behaviour of a negative $length would be the same as for
stream_copy_to_stream.
The current behaviour for negative lengths < -1 is to interpret them as
unsigned lengths.
For lengths == -1 the behaviour is to copy everything.
I don't see how this is different from for example very large lengths and an
unknown stream length.
I don't really understand your concern here. Could you please elaborate on the
problem you see?
> fpassthru() is largely a convenience wrapper around fread()/unbuffered echo
> in a loop with some extra output buffer management and is subject to PHP
> max_execution_time. For large files and/or slow/high latency networks, PHP
> can timeout before delivering all content.
>
> There are several web server extensions available (X-Sendfile and
> X-Accel-Redirect) where, for local files, the rest of the request can be
> handed off from PHP to the web server to completely avoid writing any file
> output to the output buffer and also avoid timeout issues. The existence of
> modern web server extensions for all major web servers limits the overall
> usefulness of fpassthru(). IMO, $length should be added for language-level
> completeness/convenience but it might also be a good idea to mention
> X-Sendfile/X-Accel-Redirect in the documentation for fpassthru() so that
> users are encouraged to leverage resource-efficient technologies wherever
> possible.
>
I agree it's a good idea to add this to the manual, although it should be noted
that not every place where PHP is provided for hosting has this functionality
available.
>
>> Ended up with a
>> $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
>> hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
>> the way)
>>
>>
>> On Sat, Feb 11, 2023, 15:26 Niels Dossche wrote:
>>
>>> Dear internals
>>>
>>> I would like to gain RFC karma for creating and proposing an RFC:
>>> "Implement GH-9673: $length argument for fpassthru".
>>> Account name: nielsdos
>>>
>>> Thanks in advance
>>> Kind regards
>>> Niels
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC karma request
Good point, and come to think of it, people wishing to $offset can fseek()
before before fpassthru() anyway. Nevermind the $offset thing, it's more
trouble than it's worth ^^
On Sun, Feb 12, 2023, 15:46 Thomas Hruska wrote:
> On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:
> > Fwiw I would also find an $offset argument useful. fpassthru's lack of
> both
> > $length and $offset made my life harder when implementing "HTTP 206
> Partial
> > Content" / "HTTP range requests",
>
> I was going to suggest this myself until I realized that an $offset
> parameter would be rather problematic. What happens if the offset is
> negative? Does a negative offset mean seek backwards from the current
> position OR start at that many bytes from the end of the stream? Is the
> offset a seek operation or a read operation? Not all streams are
> seekable and reading is generally a fairly slow, blocking I/O operation.
> Also, not all stream lengths are known. A negative offset in
> non-seekable scenarios would almost certainly have to throw an error.
> fseek()/fread() are more flexible and consistent for getting to the
> desired starting point in a source stream.
>
> A negative $length would also present some issues. Again, not all
> stream lengths are known. Correctly handling negative values would
> require managing an internally, temporarily allocated buffer of
> sufficient size to be able to backtrack streams of unknown length. And
> might even have to cache the entire stream in RAM, which would be
> problematic for 1GB+ streams. Or just throw an error for such streams.
> Or just restrict $length to non-negative values only.
>
> In short, a non-negative, nullable $length parameter is the only
> well-defined operation for fpassthru().
>
> fpassthru() is largely a convenience wrapper around fread()/unbuffered
> echo in a loop with some extra output buffer management and is subject
> to PHP max_execution_time. For large files and/or slow/high latency
> networks, PHP can timeout before delivering all content.
>
> There are several web server extensions available (X-Sendfile and
> X-Accel-Redirect) where, for local files, the rest of the request can be
> handed off from PHP to the web server to completely avoid writing any
> file output to the output buffer and also avoid timeout issues. The
> existence of modern web server extensions for all major web servers
> limits the overall usefulness of fpassthru(). IMO, $length should be
> added for language-level completeness/convenience but it might also be a
> good idea to mention X-Sendfile/X-Accel-Redirect in the documentation
> for fpassthru() so that users are encouraged to leverage
> resource-efficient technologies wherever possible.
>
>
> > Ended up with a
> > $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
> > hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
> > the way)
> >
> >
> > On Sat, Feb 11, 2023, 15:26 Niels Dossche
> wrote:
> >
> >> Dear internals
> >>
> >> I would like to gain RFC karma for creating and proposing an RFC:
> >> "Implement GH-9673: $length argument for fpassthru".
> >> Account name: nielsdos
> >>
> >> Thanks in advance
> >> Kind regards
> >> Niels
>
>
> --
> Thomas Hruska
> CubicleSoft President
>
> CubicleSoft has over 80 original open source projects and counting.
> Plus a couple of commercial/retail products.
>
> What software are you looking to build?
>
>
Re: [PHP-DEV] [VOTE] include cleanup
On Sun, 12 Feb 2023 at 09:31, Max Kellermann wrote: > > On 2023/02/11 17:14, Peter Kokot wrote: > > I've voted in favor of the RFC because of the code-cleaning, > > tech-debt-reducing improvements to code readability. > > Exactly my point, and I'm surprised by the resistance. > > Not only surprised, but also disappointed that many have voted against > code cleanup, but where have those people been when this was being > discussed? > > Matthew said there had been "chatter from a number of folks after the > changes were merged about builds no longer compiling", but was not > able to render that more precisely. > > None of that was discussed on GitHub nor here on php-internals. I > have to question whether these build breakages even exist. > > (Other than the DTrace build failure which happened because one line > was missing, but that's a fact and not "chatter", and one bug reporter > and not "a number of folks". Let's put this dead horse to rest.) > > > > BTW, merging from PHP 8.1 up is not problematic. Git diff only looks > > at a few lines of code above and below. Not the top of the file. > > This was the only counter-argument ever discussed here, and I'm > puzzled that the imagination of merge conflicts scares so many people. > About a kind of change that is unlikely to cause one. > > Any code change can cause a merge conflict, but include cleanups are > the least likely cause of all, because include directives are almost > never touched in bugfix-only branches. > > > Is that all, or is there another, yet unnamed reason why there's so > much resistance? The hearsay about build failures? > > > There are 3 more days to vote, and it's a tie currently - means 9 > "YES" votes missing for supermajority or else the RFC gets rejected. > That rejection would not only be a missed chance to modernize the PHP > code base, but also a sign to potential PHP contributors that the PHP > maintainers don't value clean code. This is unsettling. > > Imagine how this will overshadow future attempts to remove historical > cruft from a decades-old code base, because the counter-arguments > apply the same to any kind of code cleanup. As any decades-old code > base, there's a lot of historical cruft in PHP which gets in the way > all the time, much more than a hypothetical one-time merge conflict. > Historical cruft keeps piling up if you don't keep cutting it down all > the time. > > Cleaner code is easier to read and understand, which makes existing > bugs easier to fix and makes new bugs less likely to be added. That > outweighs, in my opinion, all the possible disadvantages that the > process of code cleanup could possibly have, by orders of magnitude. > > Max Well, the PHP long-term maintainers are just a bit stubborn when it comes to such changes and probably what concerns them is writing code styles in stone. We shouldn't conclude that the PHP team as a whole doesn't care about clean code based on this voting. People just need a bit of time to grasp the changes and discuss these things over a longer period. They just care more about the stability of the current repo and the extensions out there than the cosmetics of the ASCII characters in files. I agree though, that both sides need to be improved. One more question here. Is the iwyu (include-what-you-use) tool used here to clean up these header files? I'm assuming something like this could be one day executed: iwyu --no_fwd_decls --no-comments Based on this, this is an awesome tool and can improve the code. I'd say to go hand in hand here and one day later discuss things like this again to integrate these gradually. Automating is always tricky on the other hand. Like adding the iwyu step in the build checks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC karma request
On 2/12/2023 5:47 AM, Hans Henrik Bergan wrote:
Fwiw I would also find an $offset argument useful. fpassthru's lack of both
$length and $offset made my life harder when implementing "HTTP 206 Partial
Content" / "HTTP range requests",
I was going to suggest this myself until I realized that an $offset
parameter would be rather problematic. What happens if the offset is
negative? Does a negative offset mean seek backwards from the current
position OR start at that many bytes from the end of the stream? Is the
offset a seek operation or a read operation? Not all streams are
seekable and reading is generally a fairly slow, blocking I/O operation.
Also, not all stream lengths are known. A negative offset in
non-seekable scenarios would almost certainly have to throw an error.
fseek()/fread() are more flexible and consistent for getting to the
desired starting point in a source stream.
A negative $length would also present some issues. Again, not all
stream lengths are known. Correctly handling negative values would
require managing an internally, temporarily allocated buffer of
sufficient size to be able to backtrack streams of unknown length. And
might even have to cache the entire stream in RAM, which would be
problematic for 1GB+ streams. Or just throw an error for such streams.
Or just restrict $length to non-negative values only.
In short, a non-negative, nullable $length parameter is the only
well-defined operation for fpassthru().
fpassthru() is largely a convenience wrapper around fread()/unbuffered
echo in a loop with some extra output buffer management and is subject
to PHP max_execution_time. For large files and/or slow/high latency
networks, PHP can timeout before delivering all content.
There are several web server extensions available (X-Sendfile and
X-Accel-Redirect) where, for local files, the rest of the request can be
handed off from PHP to the web server to completely avoid writing any
file output to the output buffer and also avoid timeout issues. The
existence of modern web server extensions for all major web servers
limits the overall usefulness of fpassthru(). IMO, $length should be
added for language-level completeness/convenience but it might also be a
good idea to mention X-Sendfile/X-Accel-Redirect in the documentation
for fpassthru() so that users are encouraged to leverage
resource-efficient technologies wherever possible.
Ended up with a
$output = fopen('php://output', 'wb'); + stream_copy_to_stream()
hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
the way)
On Sat, Feb 11, 2023, 15:26 Niels Dossche wrote:
Dear internals
I would like to gain RFC karma for creating and proposing an RFC:
"Implement GH-9673: $length argument for fpassthru".
Account name: nielsdos
Thanks in advance
Kind regards
Niels
--
Thomas Hruska
CubicleSoft President
CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.
What software are you looking to build?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC karma request
On 12/02/2023 13:47, Hans Henrik Bergan wrote:
> Fwiw I would also find an $offset argument useful. fpassthru's lack of both
> $length and $offset made my life harder when implementing "HTTP 206 Partial
> Content" / "HTTP range requests",
>
> Ended up with a
> $output = fopen('php://output', 'wb'); + stream_copy_to_stream()
> hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
> the way)
>
>
> On Sat, Feb 11, 2023, 15:26 Niels Dossche wrote:
>
>> Dear internals
>>
>>
>> I would like to gain RFC karma for creating and proposing an RFC:
>> "Implement GH-9673: $length argument for fpassthru".
>> Account name: nielsdos
>>
>>
>> Thanks in advance
>> Kind regards
>> Niels
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>>
>
I agree, it's also even more consistent with the other PHP functions, which I
like.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC karma request
Fwiw I would also find an $offset argument useful. fpassthru's lack of both
$length and $offset made my life harder when implementing "HTTP 206 Partial
Content" / "HTTP range requests",
Ended up with a
$output = fopen('php://output', 'wb'); + stream_copy_to_stream()
hack because of fpassthru's shortcomings (Thanks to cmb for that hack, by
the way)
On Sat, Feb 11, 2023, 15:26 Niels Dossche wrote:
> Dear internals
>
>
> I would like to gain RFC karma for creating and proposing an RFC:
> "Implement GH-9673: $length argument for fpassthru".
> Account name: nielsdos
>
>
> Thanks in advance
> Kind regards
> Niels
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] 'Uninitialized' creates a lot of cluttering
Hi
On 2/12/23 12:11, Lydia de Jongh wrote:
In case I make a mistake and accidentally don't assign a value to the
property when I should've, perhaps I've forgot to call the necessary
setter in my constructor. If I later access the property it will blow up
instead of silently feeding me garbage data.
I think this should not be an argument on this level.
The features of a programming-language should not be about preventing
mistakes, imho.
Why not? The primary (and possibly only) reason for an expressive type
system is preventing mistakes from happening and thus cutting down the
time spent writing tests and debugging. Preventing as many (expensive)
mistakes from happening as possible is also one of the selling points of
modern programming languages like Rust.
Else would it be possible to make a php.ini setting for this:
only_explicit_property_init = true|false?
New php.ini settings that change the behavior of code depending on where
it's run are generally ill-received nowadays. Library authors would need
to take care to support all possible options for the setting, which in
this case would effectively mean making all initialization explicit,
nullifying whatever benefit the option would bring in the first place.
Adding special logic for nullable properties to save the developer from
typing the 7 characters '= null;' in some rare cases, does not sound
useful to me.
For me it is about the cluttering in an otherwise clean property list.
On the other hand, so many new features in php8 are about less coding.
Shorter ifs, nullable operators, setting properties directly in
constructor.
For a long time I refused to use those, and used the longer typing, because
it is seen better, more explicit and so gives less errors.
$oObject?->test()
is much easier overlooked then:
if($oObject){
$oObject->test();
}
So I do not understand why things like this may not be about less coding.
I'm not sure the comparison holds. Staying with your example for the
null-safe operator:
Using the null-safe operator is still explicit about the developer's
intent: The question-mark makes it clear that the developer thought
about the fact that the object variable might be null and that
short-circuiting to null is the right thing to do.
Allowing leaving out a default value for the property can mean both "I
explicitly want it to be null" and "I forgot to set the property".
Whereas with the current situation of "uninitialized", the former is
explicit and the latter will result in an easily detectable error,
instead of silently continuing execution with garbage data.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] 'Uninitialized' creates a lot of cluttering
Hi,
Thanks for all the answers so far.
On 2/8/23 17:04, naitsi...@e.mail.de wrote:
> > Would it make sense to make "null" the default value for nullable
properties at least?
> > So that one could write
> >
> > class Test {
> > public ?string $name;
> > }
> >
> > var_dump((new Test())->name); // null
>
Yes, this would help a lot and is exactly what I am asking for.
Then the difference between typed and none-typed properties would also
disappear. Making it more favorable to use the typed ones.
Op wo 8 feb. 2023 om 17:34 schreef Tim Düsterhus :
>
>
No, I find the difference between "null" and "uninitialized" useful,
> because it makes the behavior explicit.
>
In case I make a mistake and accidentally don't assign a value to the
> property when I should've, perhaps I've forgot to call the necessary
> setter in my constructor. If I later access the property it will blow up
> instead of silently feeding me garbage data.
I think this should not be an argument on this level.
The features of a programming-language should not be about preventing
mistakes, imho.
Else would it be possible to make a php.ini setting for this:
only_explicit_property_init = true|false?
Adding special logic for nullable properties to save the developer from
> typing the 7 characters '= null;' in some rare cases, does not sound
> useful to me.
For me it is about the cluttering in an otherwise clean property list.
On the other hand, so many new features in php8 are about less coding.
Shorter ifs, nullable operators, setting properties directly in
constructor.
For a long time I refused to use those, and used the longer typing, because
it is seen better, more explicit and so gives less errors.
$oObject?->test()
is much easier overlooked then:
if($oObject){
$oObject->test();
}
So I do not understand why things like this may not be about less coding.
Op wo 8 feb. 2023 om 19:12 schreef Rowan Tommins :
>
> I've actually been considering a proposal to remove this difference *the
> other way around*: if a property is declared but never assigned a value,
> consistently giving an error on access, regardless of whether a type was
> declared or not.
>
>>
> Currently, properties can be in a number of different states: declared and
> assigned, undeclared, undeclared but created dynamically by assignment,
> declared without type and not yet assigned, declared with type and not yet
> assigned (Uninitialized), declared without type but then unset (distinct
> from both the unassigned and Uninitialized states) ... possibly other
> combinations I've forgotten.
>
Lol, sounds horrible indeed!
>
> Now that we have the Uninitialized state, and have deprecated dynamic
> properties, this could mostly be reduced to two: has a current valid value,
> or Uninitialized. But the details of what would need to change and when are
> the subject for a future discussion.
>
Sounds much better!
And I think that implicit null on nullable properties could fit nicely
here. For null is a valid value for a nullable.
So I still would like to ask if you can reconsider this.
nb. Maybe I should introduce myself a little bit (more): I have been a
php-programmer for about 20 years now, seen php4, 5, 7 and now 8. I did my
study on Ambi Cobol to be an application programmer, where I learned very
strict coding. From my ex (java architect) I learned oop. I have used these
programming rules/techniques in php even when it was not required.
So it is not that I want php to be less strict!!! (just to be sure )
Greetz, Lydia
Re: [PHP-DEV] [VOTE] include cleanup
On 2023/02/11 17:14, Peter Kokot wrote: > I've voted in favor of the RFC because of the code-cleaning, > tech-debt-reducing improvements to code readability. Exactly my point, and I'm surprised by the resistance. Not only surprised, but also disappointed that many have voted against code cleanup, but where have those people been when this was being discussed? Matthew said there had been "chatter from a number of folks after the changes were merged about builds no longer compiling", but was not able to render that more precisely. None of that was discussed on GitHub nor here on php-internals. I have to question whether these build breakages even exist. (Other than the DTrace build failure which happened because one line was missing, but that's a fact and not "chatter", and one bug reporter and not "a number of folks". Let's put this dead horse to rest.) > BTW, merging from PHP 8.1 up is not problematic. Git diff only looks > at a few lines of code above and below. Not the top of the file. This was the only counter-argument ever discussed here, and I'm puzzled that the imagination of merge conflicts scares so many people. About a kind of change that is unlikely to cause one. Any code change can cause a merge conflict, but include cleanups are the least likely cause of all, because include directives are almost never touched in bugfix-only branches. Is that all, or is there another, yet unnamed reason why there's so much resistance? The hearsay about build failures? There are 3 more days to vote, and it's a tie currently - means 9 "YES" votes missing for supermajority or else the RFC gets rejected. That rejection would not only be a missed chance to modernize the PHP code base, but also a sign to potential PHP contributors that the PHP maintainers don't value clean code. This is unsettling. Imagine how this will overshadow future attempts to remove historical cruft from a decades-old code base, because the counter-arguments apply the same to any kind of code cleanup. As any decades-old code base, there's a lot of historical cruft in PHP which gets in the way all the time, much more than a hypothetical one-time merge conflict. Historical cruft keeps piling up if you don't keep cutting it down all the time. Cleaner code is easier to read and understand, which makes existing bugs easier to fix and makes new bugs less likely to be added. That outweighs, in my opinion, all the possible disadvantages that the process of code cleanup could possibly have, by orders of magnitude. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
