PHP RFC: Random Extension Improvement

• Version: 1.0
• Date: 2022-06-16
• Author: Go Kudo g-kudo@colopl.co.jp zeriyoshi@gmail.com
• Status: Under Discussion
• First Published at: http://wiki.php.net/rfc/rng_extension

There are several issues with RFC: Random Extension 5.x that are already in the voting phase due to lack of proper discussion.

Key issues include:

The Random Extension has classes that are natively implemented as RNG engines, but they are not marked as final. This allows classes to be created that inherit from native classes, but as stated in the previous RFC, user-implemented engines are inferior to native classes in terms of execution efficiency. This is true even for inheritance without method overrides, which often leads to confusion.

The extension already provides a Random\Engine interface with a single generate(): string method. Even if the native classes are made final, it is easy for the user to create an alternative class using delegates.

This is clearly an API design error, and the native implementations of the interface should be marked as final.

array_rand() uses RNG internally, but there is no alternative method in Randomizer. As per the previous RFC, this was the intent, but upon further investigation, array_rand() is used by many packages and should probably be drop-in replaceable.

However, the name of the method may need to be reconsidered. How about Randomizer::pickArrayKey(array $array, int $num = 1): int|string|array or something similar?

In PHP, “string” means a binary. This is often a problem when using multibyte characters. For example, str_shuffle on a Japanese (UTF-8) string will give messed up results.

Therefore, it may be better to change the alternative method of str_shuffle(), Randomizer::shuffleString(), to Randomizer::shuffleBytes(). This is a more appropriate name.

The Random Extension has implemented PCG64 as a new PRNG, but it is officially one variant of PCG64, oneseq-128-xsl-rr-64, and may need to be made more easily understood.

Therefore, change the class name from Random\Engine\PCG64 to Random\Engine\PcgOneseqXslRr64.

When PCG makes the choice to reflect a more detailed implementation in the name, Random\Engine\MersenneTwister is also an issue at the same time.

Random\Engine\MersenneTwister is precisely an implementation of the MT19937 algorithm.

MT19937 also has an algorithm called MT19937_64 that generates 64-bit values. If for some reason MT19937_64 were to be implemented, the fact that the name Mersenne Twister is already in use could be problematic.

PCG is a very good algorithm, boasting great randomness and performance.

However, I think its name recognition is in some ways inferior to Vigna's RNG, which started with Xorshift.

Therefore, I reimplement Xoshiro256**, which was previously mentioned as a candidate, and create the class Random\Engine\Xoshiro256StarStar. This will avoid the problem of using the old MT19937 since it is not familiar with PCG.

PHP applies strict PascalCase to class names. However, the previous RFC implementation does not properly meet the requirements.

So, rename the class as follows:

• Random\Engine\CombinedLCG -> Random\Engine\CombinedLcg
• Random\Engine\PCG64 -> Random\Engine\Pcg64 (or PcgOneseqXslRr64)
• (Random\Engine\MT19937 -> Random\Engine\Mt19937)

For each of these issues, we will create a ballot option and make a decision.

The following names have been reserved and will no longer be available (optional):

• Random\Engine\Pcg64OneseqXslRr64
• Random\Engine\Xoshiro256StarStar (optional)
• Random\Engine\MT19937

8.2

none

none

none

none

none

currently none

• https://externals.io/message/117939