Hi! > I don't understand the drive to holding on to obviously faulty stuff.
What is for you "obviously faulty stuff" for literally thousands of people is "code that works". I appreciate that there's a number of new hip randomness tests that mt_rand may not satisfy, and there's new and exciting number generator that we absolutely must implement because it's new and exciting, but most users of mt_rand wouldn't really care, and breaking their code for no reason that we have new and exciting RNG is not what they would appreciate. > 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. If we're not going to remove it, there's no reason to pollute the logs with useless messages. If you want to tell people about better alternatives, there's the manual for that. > 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. The users that do not wish to upgrade just won't upgrade. Making them jump through hoops just to have what they already have makes no sense. > Where is the drive coming from? Simple: getting towards a cleaner > language that does not include cruft. This is a meaningless statement. "Cruft" is entirely subjective and undefined, you essentially are saying "the language should look the way I like it and contain only the code and syntax I like". That can not work in a mature language with gigabytes of deployed code out there. > 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 No and no. > 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 "Trying to get rid of" is not going to help people that have code bases rooting in PHP 4. And that's the majority of deployed code. It would be enormous expense to convert all that code - and all that expense would serve absolutely no goal except giving you satisfaction of "there's no cruft". It is a useless goal and any time spent on reaching it is wasted. > 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 Your company may have tons of money and manpower to rewrite their code (and, I assume, every library you use and every dependency that library has) every 2-3 years. Most companies most definitely do not. Our usage numbers for latest versions are very bad - 5.3 is still the most used PHP version. We do not need to make upgrading harder. In fact, if we make it any substantially harder, I don't know who we'll be releasing it for - 0.01% of PHP user base that would actually run it? > 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 Did I misunderstand you or you just claimed nobody wants to code in PHP because it has var and rand and there's impossible to find a PHP developer on the market? I am afraid my experience is exactly the opposite. But if you are worried about this, making it harder to work with PHP by fragmenting the ecosystem and making people remember which function does random in which PHP version is not going to help. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
