Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127316
Date: Wed, 07 May 2025 22:36:26 +0000
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility
Message-ID: <RG1BNbOBzyHzqarQLUv0aO6cvo2ePyZ-Tt_bgRKR_9rSX_4glhTaHCx54Y9ykWXY_NzNgEUSu4yWv3hq0qIKZmCu15umaQmgjUPp62iz2A4=@gpb.moe>
In-Reply-To: <0433FF37-D938-4D3D-AC03-E5143218EFEA@cschneid.com>
References: <CAPTD5yFaQL58uJ3Focij9HKT-u-70fTDdzBWsqxpAru2YRZaqQ@mail.gmail.com> <YAFPTpeOTAw7NcYOqaFhRhEMMZTLzLtqVbMlPKWI-P2FwlxvoOfdKBQWyxO8Y_uXA903u1fwjP7reP45oyfvbyHy_W7gnP4HIrWxXP1TE7Y=@gpb.moe> <0433FF37-D938-4D3D-AC03-E5143218EFEA@cschneid.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Wednesday, 30 April 2025 at 13:16, Christian Schneider <cschneid@cschnei=
d.com> wrote:

> Am 27.04.2025 um 20:22 schrieb Gina P. Banyard internals@gpb.moe:
>=20
> > I fundamentally reject the concept of this RFC to restrict our ability =
to do input validation.
>=20
>=20
> I am sorry but I fail to see how the RFC restrict the ability to do input=
 validation.
>=20
> [...]
>=20
> > 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 pr=
oduction, that might end up hard to debug.
> > We throw Errors on non-existent constants, functions, classes, etc. for=
 a reason.
>=20
>=20
> I am not against error-ing on invalid input, and I don't think anyone els=
e is.
> It is all about the migration path for existing software and having guide=
lines for such changes.
>=20
> Using intermediate warnings before going to an Exception allows updating =
an installation step-by-step instead of all at once. Which is important bot=
h for projects using a lot of composer packages as well as installations wh=
ere PHP and applications are maintained by different people (e.g. hosting c=
ompanies).
>=20
> Case-studies regarding implicitly nullable parameters and the warning pha=
se:
> - 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
>=20
> Sure, this is from one minor version to the next and not about invalid ar=
gument values and it uses E_DEPRECATED instead of E_WARNING but my main poi=
nts stays the same:
> If this would have been done without warning phase then it would be a blo=
cker for upgrading to PHP 8.4, now filtering this warning is enough while t=
he packages are being updated.

Comparing a core language change to be the same level as throwing a ValueEr=
ror on invalid inputs of a bundled extension function is a bit of a straw m=
an argument.
The motivation for this policy change is _explicitly_ about input validatio=
n.

> And I am of the very strong opinion that the benefits of reducing frictio=
n 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 hel=
per 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 red=
uce my contributions to the project.
> > As it would be a clear sign to me that what people want from the projec=
t 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.
>=20
>=20
> 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 i=
mprove even it is sometimes in different ways.

I am entitled to my strong opinions as someone that has provided over 700 r=
eviews to php-src PRs and over 800 reviews to doc PRs in 2024, on top of al=
l my own code, documentation, and internal email contributions.
This gives me a very broad overview of the state the whole PHP project is i=
n, and claiming that everything can "just be done at a later date easily" i=
s a completely unrealistic worldview.
Moreover, I know that I am speaking for at least a few other core contribut=
ors that don't want to engage more than necessary on this mailing list, con=
sidering how draining it can be.

So yes, if the community thinks the way I've been reviewing and contributin=
g to the project is wrong, then severely reducing my contributions is the o=
nly reasonable step.
You consider it pressure, I consider it communicating how I feel about cont=
ributing to the project, which has already been less enjoyable than before =
for a while.


Best regards,

Gina P. Banyard