On Thu, Dec 24, 2020 at 5:12 PM zeriyoshi <zeriyo...@gmail.com> wrote:
> I updated the RFC draft and changed it to a proposal to bifurcate the > interface. > > https://wiki.php.net/rfc/object_scope_prng > > At the same time, I was looking into the RNG problem in Swoole and found > out that the problem was actually occurring. > > https://www.easyswoole.com/En/Other/random.html > > The above problem with Swoole is only for child processes and can be fixed > by the user, but as mentioned above, I think it will become more serious as > PHP becomes more complex in the future. > I hadn't thought of this before, but we might want to consider deprecating > existing state-dependent RNG functions. > > I am seeking feedback on this proposal in order to take the RFC to the next > step. > Thank you in advance. > > Regards, > Go Kudo > I think the general direction of your second proposal (B) is the right one, but I'm concerned about some of the details. First and foremost, I don't think that RNG should extend Iterator. Just having a single "next()" method or similar is sufficient. The Iterator interface provides many additional things that don't really make sense in this context and only complicate the implementation. We should clearly specify the value range of next() though. I assume that for portability reasons (ensure same sequence on 32-bit and 64-bit) this would have to be a sign-extended 32-bit value. The type B proposal distinguishes between a RNG and a PRNG interface. Is this really useful? I don't think the value of the "getSeed()" method is high enough to justify the split interface. The RNGUtil class has methods like: public static function shuffleArray(int $randomNumber, array $arr): array; This doesn't make sense to me, as a single random number is not enough to shuffle a whole array :) Instead this should be accepting the RNG and perform an internal call to next() (of course, with a fast by-pass mechanism if the RNG is implemented internally): public static function shuffleArray(RNG $rng, array $arr): array; I'm also wondering why this is a static class rather than a set of free-standing functions. Why RNGUtil::shuffleArray() rather than rng_shuffle_array()? Regards, Nikita 2020年12月16日(水) 23:46 zeriyoshi <zeriyo...@gmail.com>: > > > Nice to meet you, internals. > > > > PHP 8.0 has been released. With the inclusion of JIT, PHP is about to be > > extended beyond the web. > > > > So I'd like to make a few suggestions. > > > > First , PHP has the historical Mersenne Twister PRNG. However, this > > implementation keeps its state in a global and cannot be handled as an > > object like other languages (e.g. Java). > > > > So, I created a PHP Extension and proposed it to PECL. > > > > https://marc.info/?l=pecl-dev&m=160795415604102&w=2 > > https://github.com/zeriyoshi/php-ext-orng > > > > But, Then I looked at the mailing list archives and noticed that a > similar > > proposal had been made before. > > > > https://externals.io/message/98021#98130 > > > > I feel that this suggestion is needed now to expand PHP beyond the web. > > > > Second suggestion is to stop using the Combined LCG as the default seed > > value for each function. > > > > PHP's Combined LCG only uses PID (or ZTS Thread ID) and time as entropy. > > https://github.com/php/php-src/blob/master/ext/standard/lcg.c#L72 > > > > With the development of container technology, this problem seems to be > > getting more serious. So I think we should use the random numbers > provided > > by the OS (getrandom on Linux) if available. > > > > I would like to hear your opinions. > > > > Regards > > Go Kudo <zeriyo...@gmail.com> > > >
