> I'm still unclear how I'd write my own NumberGenerator right now. I mean, I can extend the class, but I don't have a sense for what I'd do with it for non-testing/trivial implementations. You say it's using an internal function to generate numbers, but in user space what would I do with that? And when/why would I?
For example, I will create an application that does a lottery. I need to estimate the load and test it. If I actually use random numbers to draw the lots, the test results will be different each time. It is true that this example can be solved by devising a better implementation of the userland. If this is the case, you may be wondering why we implement it this way. Currently, there are several implementations of random number generators written in PHP. https://github.com/savvot/random Although not in this library, I use an in-house interface that is completely replaceable with random_int() for load testing in my production brother. Also, JIT was implemented in PHP 8.0. which has the potential to make it possible to write in PHP what would otherwise have to be implemented in C due to execution speed issues. In fact, the random number generator written in PHP for my tests shows a significant performance improvement when JIT is enabled. The ability to have a workable random number implementation in userland should be useful for future extensions. > Is the intent that I should stop using random_int()? No, it's not. random_int() is a safe and easy CSPRNG, and is recommended for future use. The advantage of using Random\NumberGenerator\Secure is that it can shuffle strings/arrays using the same random number source as random_int(). Something that is not included in this RFC but that I would like to deprecate in the future is the mt_srand (srand) function. These have internal state and are very harmful for extensions such as Swoole: Also, shuffle() and str_shuffle() are very good functions, but I don't think they should use the random number source generated by mt_srand. The user may unintentionally use an unsecured random number. I apologize for the difficulty in conveying this message. I've revised the wording. > Changes random source to php_random_int() in shuffle(), str_shuffle(), and array_rand() . 2021年9月3日(金) 23:04 Larry Garfield <la...@garfieldtech.com>: > On Fri, Sep 3, 2021, at 8:55 AM, Go Kudo wrote: > > Thank you. > > > > > Why is the number generator a parent class rather than an interface? > > > > This is an implementation limitation. I could not find a way to define my > > own object handler in interface. > > As Nikita pointed out in a previous suggestion, the NumberGenerator now > > uses php_random_ng_algo_user to generate random numbers faster than > before, > > even if it is a userland implementation. > > I'm still unclear how I'd write my own NumberGenerator right now. I mean, > I can extend the class, but I don't have a sense for what I'd do with it > for non-testing/trivial implementations. You say it's using an internal > function to generate numbers, but in user space what would I do with that? > And when/why would I? > > > > You don't mention the CSPRNG functions at all. > > > > This is a mistake. I have corrected it. Thanks! > > I'm still not clear on the intent here. Is the intent that I should stop > using random_int()? And if so, replace it with... what? Do I have to > supply a specific non-default generator? That makes the usability worse, > and more likely to be gotten wrong. > > Also, in future scope you you have this sentence, which makes little sense: > > >> Replace random_bytes() with random_bytes() for random numbers used in > shuffle(), str_shuffle(), and array_rand(). > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
