On 6/21/2016 11:41 AM, Jordi Boggiano wrote: > On 21/06/2016 06:33, Stanislav Malyshev wrote: >> Hi! >> >>> Why do we need so many functions to get a random int anyways if we now >>> have random_int()? I would like to see all of them deprecated and >>> removed in PHP 8.0. >> >> I don't understand this drive to remove functions and break existing >> code. What is the point of it? If you don't like them, don't use them. >> They can share underlying implementation but there's absolutely no >> reason to remove functions unless they do not work anymore, broken and >> can not be fixed, etc. > > I agree that removing such widely used functions should be done > extremely carefully, but marking them deprecated might be a good idea if > there is a stronger alternative available. That way we encourage people > to migrate, and at some point (PHP 9, 10, never, who knows) maybe they > are unused enough that we can remove them safely. > > Same with magic quotes and such, it took 10 years, but they are finally > gone. > > Cheers >
I don't understand the drive to holding on to obviously faulty stuff. Nikic proposed already to deprecate rand() and I am only saying that we can go one step further and implement pcg_rand() in favor of mt_rand() and deprecate mt_rand(). Probably not something we want to do in 7.1 (because PCG needs some more time to mature) but something that we might want to do on the road to PHP 8.0. Deprecation is not the same as "simply removing and breaking all existing code". It is just a deprecation that usually means a log entry, if at all. Removal does not mean that we need to delete the code and get rid of it forever. We can move the functionality to PECL and/or supply userland polyfills for users who do not which to upgrade. Where is the drive coming from? Simple: getting towards a cleaner language that does not include cruft. Cleaning APIs is a totally normal process. We just need to do it carefully without BCs within minor or patch versions (which would now allow me to make a potshot right due to some other RFCs) and without introducing too many for the next major version because it makes upgrading too complicated because too many LOCs need to be touched in order to upgrade some software. The var keyword was a good example of something that can safely be deprecated and removed later but the rand stuff here is too. We already have alternatives available (public, private, protected for var) (random_int and mt_rand for rand) or the ability to implement good alternatives (pcg_rand). The general community that is actively developing software is already trying to get rid of the usage of both (var and rand) and is only using mt_rand because there are no other alternatives available (random_int was introduced with PHP 7 but the community has developed a polyfill for themselves). I do not understand the fear to deprecate cruft or badly designed stuff from time to time. I am working at a big company that has a lot of legacy PHP code but we are not afraid to actively invest into making it better. We were actually one of the first big players to change to PHP 7 and this was even shared by Rasmus on his Twitter account. Yes it is time consuming, yes it takes man power, but we are willing to invest it in order to see increased performance, security, testability, and readability of our code since our code is what makes our applications and our applications is what makes our money. In the same vein, searching for PHP developers is a hard thing because of all the various complains that we all know of and are already fed up with. If we would just start addressing those issues things would change over time in this field too and at some point it is as easy as finding a Java developer as it is to find a proper PHP developer. Sorry for going so off topic but you asked for my drive and that is part of it. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
