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. > You don't mention the CSPRNG functions at all. This is a mistake. I have corrected it. Thanks! I will keep an eye on it throughout the next week, and if there are no additional responses, I will start voting the week after next. Regards, Go Kudo 2021年9月3日(金) 3:26 Larry Garfield <la...@garfieldtech.com>: > On Thu, Sep 2, 2021, at 10:10 AM, Go Kudo 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. > > > > Regards, > > Go Kudo > > This looks pretty nice to my unskilled eye. Two questions. > > 1) Why is the number generator a parent class rather than an interface? > It seems like an interface target. And either way it needs more clarity > about how you'd write one for reals. (It returns an int, so does that mean > getBytes() just derives from a series of ints?) > > 2) You don't mention the CSPRNG functions at all. Is there any intention > to fold those into this model as well, or to leave those as is? Or is the > Secure generator implementation intended to replace those? It's unclear > here. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
