I have made some fixes to the implementation based on review. The current implementation can be found at the following address (Thanks Tyson: https://github.com/zeriyoshi/php-src/commit/5ff8882a8fbfaf4ffd5cc42fb5853c4a1a00c182 )
https://github.com/php/php-src/compare/master...zeriyoshi:object_scope_rng_type2 The points that seem to need discussion at the moment are as follows: - Do we need this feature? First of all this is more important than anything else. I think it is necessary from a testing perspective and because it is going to be difficult to consider global state in the future and some functions are using RNGs at times that the user is not aware of. - Do we need support for userland implementations? I think this is necessary. Fixing the output of an RNG to an arbitrary result is useful for testing special patterns. However, this is currently problematic. At the moment, there is a complete distinction between C implementations and userland implementations. This is done based on whether the class is user-defined or not. The classes provided by the C implementation are always final and cannot be extended by the user. I would like to make it extensible if possible, but currently I don't know how to make it compatible with speed. - How do you deal with the mixed 64/32 bit issue? Some PRNGs, including XorShift128+, keep their internal state in uint64. The XorShift128+ implementation supports serialization, which preserves the internal state in a 32bit environment by converting numbers to strings. However, __construct() still accepts seed values in int. This means that certain states cannot be reproduced in a 32bit environment. I think the support for 32bit environment will be reduced, and the serialization support was done to help with the migration. Should __construct() still accept a seed value in a string, so that all states are available in a 32bit environment? - What should we do with next64()? The next64() method of the C implementation of RNG always throws a ValueError in 32bit environments for now. However, in a user implementation, everything is left up to the implementation. Personally, I think it would be better to define another interface for the next64() method that inherits from RNGInterface, what do you think? Regards, Go Kudo 2021年1月9日(土) 19:00 Go Kudo <zeriyo...@gmail.com>: > Hi internals. > > I think I'm ready to discuss this RFC. > https://wiki.php.net/rfc/object_scope_prng > > Previous internals thread: https://externals.io/message/112525 > > Now is the time to let me know what you think. > > Regards, > Go Kudo >
