Nikita, Thanks for the clarification. That's exactly what I intended to do.
> can you update the RFC with more information about this functionality? I understand. Organize them and reconstruct the RFC text. I've also created an RFC about moving RNG-related functions from ext/standard to ext/random. I would appreciate it if you could check it out. https://wiki.php.net/rfc/random_ext Regards, Go Kudo 2021年9月7日(火) 2:24 Ben Ramsey <ram...@php.net>: > Nikita Popov wrote on 9/6/21 03:06: > > On Sun, Sep 5, 2021 at 7:40 PM Ben Ramsey <ram...@php.net> wrote: > > > >> Go Kudo wrote on 9/4/21 23:00: > >>> Indeed, it may be true that these suggestions should not be made all at > >>> once. If necessary, I would like to propose to organize the RNG > >>> implementation first. > >>> > >>> Do we still need an RFC in this case? I'm not sure I'm not fully > >> understand > >>> the criteria for an RFC. Does this internal API change count as a BC > >> Break > >>> that requires an RFC? > >> > >> Yes, since re-organizing the RNG implementation is a major language > >> change that affects extensions and other downstream projects, this > >> requires an RFC. > >> > >>>> Personally, I don't see the benefit of including this OOP API in the > >> core. > >>> > >>> On the other hand, can you tell me why you thought it was unnecessary? > >>> Was my example unrealistic? > >> > >> You also said, in reply to Dan Ackroyd: > >> > >>> Either way, I'll try to separate these suggestions if necessary, but if > >> we > >>> were to try to provide an OOP API without BC Break, what do you think > >> would > >>> be the ideal form? > >> > >> The OOP API appears to be a wrapper around the RNG functions. The only > >> thing it gains by being in the core is widespread use, but it loses a > >> lot of flexibility and maintainability, since the API will be tied to > >> PHP release cycles. > >> > >> By doing this as an OOP wrapper in userland code, you're not restricting > >> yourself to release only when PHP releases, and you can work with the > >> community (e.g., the PHP-FIG) to develop interfaces that other projects > >> might use so they can make use of their own RNGs, etc. > >> > > > > The OO API is not just a wrapper around the RNG functions -- it provides > > new functionality that cannot be efficiently implemented in userland > code. > > This is for two reasons: > > > > 1. It provides independent randomness streams, which means it's not > > possible to reuse existing functionality like mt_rand() for this purpose, > > which only provides a single global random number stream. You would have > to > > reimplement the random number generator in userland. While this is > > possible, it will generally not be efficient, because PHP does not have > > native support for unsigned modular arithmetic, which is what random > number > > generators generally need. > > > > 2. It allows using functions like shuffle() and array_rand() with an > > independent randomness stream. These functions cannot be efficiently > > implemented in userland, because userland does not have random access to > > arrays. Internals can generate a random number and use it to pick the key > > at that position, which is O(1). Userland would have to call array_keys() > > first to allow random access on keys, which is O(n). > > > > Which is why I think this is a good addition to php-src. There's three > good > > reasons to include functionality in php-src (performance, ubiquity and > FFI) > > and this falls squarely into the first category. And now that we have > > fibers and need to worry more about multiple independent execution > streams, > > we also need to worry about multiple independent randomness streams. > > > > Regards, > > Nikita > > > > Thanks for the clarification, Nikita. > > The RFC says, "The Random class is a utility class that provides > functionality using random numbers." This led me to think it was a > wrapper that did not introduce new functionality. > > I can't find any discussion in the RFC on the independent randomness > streams provided by the OOP API. Go Kudo, can you update the RFC with > more information about this functionality? > > Cheers, > Ben > >
