On 19-6-2023 23:27, Máté Kocsis wrote:
Hi Juliette,
For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").
For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other RFCs that add
new features,
because functionality usually is deprecated because it is "harmful" in one
way or another. A large impact (i.e. broad usage) should not necessarily be
an
argument against deprecation. Please also keep in mind that a deprecation
is just that, a deprecation. It gives developers a heads up to migrate off
the
functionality at their own pace. We know that package maintainers are
bugged by users whenever a new deprecation message emerges in a new PHP
version,
but this doesn't mean maintainers must react right away.
Let us elaborate why we don't think impact analysis is needed here:
* As per the TYPE_CURRENCY constant is (a) completely non-functional and
(b) unfixable. As such any code that uses the constant is already broken and
the deprecation is just pointing this out, making the user aware.
* The CRYPT_* constants are possibly the least harmful part of the RFC, but
they still can be misleading to a new developer. They are trivially
polyfilled and
also trivially removed from existing code by replacing them with 1.
* MT_RAND_PHP is broken, because the sequences are not well-defined,
defeating any reason for seeding. More reasons are already given in the RFC.
* mt_rand() is everywhere and we don't believe anyone is denying that fact.
But this should not be a reason against deprecation. As the RFC outlines,
it is trivial to find this function misused with GitHub's search. We
believe that the depreciation benefit outweighs the costs for existing
users.
* ldap_connect() is already soft-deprecated in the documentation.
Regards,
The authors of th RFC
Hi Máté,
While I appreciate that _most_ of these will be low impact and are
justified, I very much disagree with that for the proposed `mt_rand()`
and friends deprecations.
There are plenty of situations where it is of absolutely no interest to
get a crypographically secure value, like for generating some
semi-random test data and I strongly believe the impact of these
deprecations to be large and fixing it won't always be trivial for
codebases which support a range of PHP versions.
As a matter of principle I believe there should be an impact analysis
for anything being deprecated. It can inform the voters as to the
appropriateness of the timing of the deprecation - early on in a major
cycle vs late in a major cycle -. Others may just take it as a FYI, but
at least they have access to the information if they wanted to assess it.
While I appreciate what you are saying about deprecations being an
"action list to migrate at your own pace", the reality for open source
packages is different as the sheer amount of deprecations over the past
few years have taken huge amounts of time to address and "leaving those
till later" is just not an option as the amount of time needed is the
same and time can only be spend once.
To give you some idea: work related to PHP 8.0 and 8.1 has been nine
months out of the year for each in my case for the open source projects
I'm involved with, so no, leaving that to later is not an option.
Smile,
Juliette
