Hi Juliette, 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.
Please note that Tim has just added a clarification regarding the removal of mt_rand(): For the Global Mersenne Twister specifically the removal will be left to an > additional later vote, allowing to defer the removal based on the remaining usage. > This means that mt_rand() will most probably have a longer phasing out period than normally, but at least this buys us time to evaluate the timeframe of the removal. I hope that we addressed your concerns. 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. > I don't think an impact analysis is useful all the time: sometimes because it doesn't make much sense *trying* to measure the impact of deprecating very rare or broken functionality (e.g. CRYPT_STD_* or the NumberFormatter::TYPE_CURRENCY constants). In other cases, the analysis is likely going to be misleading, since we don't have access to proprietary code, and some functionality is used in such code more often than in open-source projects (e.g. the typical example is session-related functions). > 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. > Please let me clarify first that we do appreciate your dedication and efforts a lot for maintaining such critical projects. At the same time, - since PHP has almost 3 decades long of track record of doing silly things -, we as maintainers are also dedicated very much about improving our language and getting rid of its unreliable/unexpected/unsafe behavior. I also do believe that we do care about our users, and it's very rare that some change is introduced without a heads up multiple years before the removal. I know these deprecations and removals usually feel like a burden for people who tirelessly work on following these changes in their open-source projects in their free time, but please do understand that PHP would still be the same crazy language without the fundamental changes which have been being introduced in the recent years. We are happy to discuss the underlying problem separately from this RFC, since the root cause may be something else than the too many deprecations, starting from things which we do not have control over (the underfincaning of open source work) to other factors which we can control (e.g. the minimum length of deprecation before the removal, shorter/longer major version cycles, educating end-users to use automation like Rector). With all that said, we're going to start the vote on Thursday, since we do believe the proposal is clear enough now, and there's not much to discuss anymore. Regards, Máté
