Re: [RFC] [Discussion] Minor version compatibility
On Wednesday, 30 April 2025 at 13:16, Christian Schneider <[email protected]> wrote:
> Am 27.04.2025 um 20:22 schrieb Gina P. Banyard [email protected]:
>
> > I fundamentally reject the concept of this RFC to restrict our ability to do input
> > validation.
>
>
> I am sorry but I fail to see how the RFC restrict the ability to do input validation.
>
> [...]
>
> > I will repeat this once again, but error-ing on invalid inputs entered by the developer is
> > an advantage.
> > I cannot comprehend the motivation to let users ship buggy code into production, that
> > might end up hard to debug.
> > We throw Errors on non-existent constants, functions, classes, etc. for a reason.
>
>
> I am not against error-ing on invalid input, and I don't think anyone else is.
> It is all about the migration path for existing software and having guidelines for such
> changes.
>
> Using intermediate warnings before going to an Exception allows updating an installation
> step-by-step instead of all at once. Which is important both for projects using a lot of composer
> packages as well as installations where PHP and applications are maintained by different people
> (e.g. hosting companies).
>
> Case-studies regarding implicitly nullable parameters and the warning phase:
> - https://github.com/hybridauth/hybridauth/releases
> with fixes for PHP 8.4 was released only last week
> - https://github.com/grpc/grpc-php still has not
> released fixes for PHP 8..4
>
> Sure, this is from one minor version to the next and not about invalid argument values and it
> uses E_DEPRECATED instead of E_WARNING but my main points stays the same:
> If this would have been done without warning phase then it would be a blocker for upgrading to
> PHP 8.4, now filtering this warning is enough while the packages are being updated.
Comparing a core language change to be the same level as throwing a ValueError on invalid inputs of
a bundled extension function is a bit of a straw man argument.
The motivation for this policy change is _explicitly_ about input validation.
> And I am of the very strong opinion that the benefits of reducing friction for upgrading to the
> current PHP version outweighs the costs. Forgetting to change the warning to an Exception can be
> simply prevented by e.g. a helper function or even a greppable code comment.
I am not saying break all the things, however, breaking clearly buggy code is something I consider a
feature.
Letting users ship buggy code in production is not something that I find at all reasonable.
And I am looking forward to your suggestion on how to simply implement this for every single unique
validation error that we encounter.
> > As such, if this policy does get accepted, I will start to severely reduce my
> > contributions to the project.
> > As it would be a clear sign to me that what people want from the project is something that
> > I find completely nonsensical and thus I should direct my energy and time to something more inline
> > with my own design beliefs.
>
>
> I find it very unfortunate that you are feeling the need to pressure the community in this way
> as I can assure you that we all want the project to improve even it is sometimes in different ways.
I am entitled to my strong opinions as someone that has provided over 700 reviews to php-src PRs and
over 800 reviews to doc PRs in 2024, on top of all my own code, documentation, and internal email
contributions.
This gives me a very broad overview of the state the whole PHP project is in, and claiming that
everything can "just be done at a later date easily" is a completely unrealistic
worldview.
Moreover, I know that I am speaking for at least a few other core contributors that don't want
to engage more than necessary on this mailing list, considering how draining it can be.
So yes, if the community thinks the way I've been reviewing and contributing to the project is
wrong, then severely reducing my contributions is the only reasonable step.
You consider it pressure, I consider it communicating how I feel about contributing to the project,
which has already been less enjoyable than before for a while.
Best regards,
Gina P. Banyard
Thread (9 messages)