Thanks nikita. > ext/standard to ext/random. Why does it do this?
There are several reasons for this. - The `random` extension name is already used by ext/standard and may interfere with the build system. - Due to the namespace rules for new extensions, it is inappropriate to rename an extension. - Due to history, the rand / mt_rand dependency is tricky and I thought it was time to sort it out. - I don't think it's a good idea to have multiple header files for a single domain feature. - As stated in the Future Scope, I wanted to be in a position to eliminate module global random number state in the future. - The existing implementation and the object implementation share most of the same logic. It was necessary to merge them into one to make them common. I certainly didn't want to require a workaround for PHP 8.2 or later for extensions that depended on ext/standard respectively, but I decided that I had no choice for the above reasons. > just don't make it a requirement. I would like to modify the design. > I don't think it makes sense to switch these functions to use cryptographic randomness by default... While these may not need to be cryptographically secure, I don't think they need to be state-dependent as well. Probably no one would look at the function name and think that it depends on the module global state. php_random_int() doesn't have any state anywhere (except OS) and can generate the requested random number. I don't see any problem with these functions using php_random_int() as a random number source. Regards, Go Kudo 2021年9月4日(土) 1:02 Nikita Popov <nikita....@gmail.com>: > On Thu, Sep 2, 2021 at 5:10 PM Go Kudo <zeriyo...@gmail.com> wrote: > >> Hi Internals. >> >> Expanded from the previous RFC and changed it to an RFC that organizes the >> whole PHP random number generator. Also, the target version has been >> changed to 8.2. >> >> https://wiki.php.net/rfc/rng_extension >> https://github.com/php/php-src/pull/7453 >> >> Hopefully you will get some good responses. >> > > This looks pretty nice to me. A few bits of feedback: > > * Unlike the previous versions of the RFC, this one also moves all of the > existing RNG-related functionality from ext/standard to ext/random. Why > does it do this? This doesn't really seem related to the problem this RFC > is solving. > > * Regarding the abstract class Random\NumberGenerator: You currently need > the abstract class, because php_random_ng is tied to the object. An > alternative design that would allow Random\NumberGenerator to be an > interface would be to make it independent of the object, such that the > structure can be allocated in the Random constructor for userland > implementations. Of course, internal implementations could still embed it > as part of their objects -- just don't make it a requirement. > > * The future scope mentions: "Changes random source to php_random_int() a > shuffle(), str_shuffle(), and array_rand()". I don't think it makes sense > to switch these functions to use cryptographic randomness by default... > > Regards, > Nikita >
