Re: [RFC] [Discussion] PHP 8.3 deprecations

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