On Wednesday, 30 April 2025 at 13:16, Christian Schneider <cschn...@cschneid.com> wrote:
> Am 27.04.2025 um 20:22 schrieb Gina P. Banyard intern...@gpb.moe: > > > 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
