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!
On 21/06/2016 18:37, Fleshgrinder wrote:
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.
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,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
