On 6/21/2016 11:40 PM, Rowan Collins wrote: > Hi, > > I already wrote this message once, but it seems to have evaporated into > the ether. So apologies if it reappears and this is revealed as a poor > duplicate of it! > > I think the push to remove "cruft" would make more sense if the > replacements were less obviously "cruft" in their own right. If I have > to polyfill pcg_rand() on old servers and mt_rand() on new ones, I'd be > tempted to just implement wtfbbq_rand() and have done with it, because > the names, and even the algorithms they represent, are pretty > meaningless to me. > > As with libsodium, I think we should avoid replacing one set of > overly-specific implementations with another, and saying "this time > we've got it right". Instead, we should look at what people actually > want the functions *for*, and hide the implementation as much as possible. > > For instance, for reproducible (seedable) random sequences, how about a > function random_int_sequence($seed, $min, $max) which returns a > generator, so you could write "$user_seq = > random_int_sequence($user_seed, 0, 10); $user_pick = $user_seq();" Or > maybe it could return a closure, or an object - either way, something to > replace the global state of (mt_)srand. > > Perhaps a random_int_fast() function with big warnings that it's not to > be trusted for crypto, but performs really well if all you're doing is > picking which image banner to show on your home page. > > Use whatever RNG you want under the hood, make a declaration of whether > or not it's stable cross-platform and cross-version, and give users an > actual reason to change their code. Then consider other use cases: a > better uniqid(), shuffling, maybe built-in UUID support... > > Then, IF the new APIs become popular, we can come back to talking about > removing rand() and mt_rand(), because we'll have replaced them with > something substantially better, not just another variant on the same thing. > > Regards, >
Yes, yes, yes! :) I would still like to deprecate rand() but probably leave it to Nikic because people actually listen to him. ;) @Tom Worster: I will not answer to any other message in this thread today but I think we are essentially on the same page regarding PCG and its suitability for PHP, it just needs time to mature. I think we also agree regarding the MT situation. However, I think that it makes sense to tackle the problem that people use mt_rand() incorrectly and Rowan's proposal here matches the last proposal I made: it's just even better and he is as always much better in summing things up. :) Maybe we could do some name brain storming? 1. random_int_sequence() 2. random_int_fast() 3. random_int_seedable() 4. random_pseudo_int() 5. pseudorandom_int() 6. random_deterministic_int() 7. deterministic_random_int() 8. ???? [1] Somehow unclear what sequence means here if you just want to randomly pick an entry from an array. [2] This might still suggest to people that they can use it for crypto, just faster. I really like it but I don't think its perfect. [3] Sounds nice to me. [4] What is a pseudo int? [5] Would create a new prefix and probably not show up in some code completions together with the other random functions. :( Other than that it would describe it best. [6] Long but to the point. [7] Again too long and it creates a shitty new prefix. The signature is clear in my opinion and exactly as Rowan had it: prng(int $seed, ?int $min = 0, ?int $max = PHP_INT_MAX): int; -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
