> but I don't think rng_rand() should support calling without arguments.
This is a backwards-compatibility leftover in mt_rand() and we should not
carry it over into a new API.
While this is true, the current implementation of MT in PHP relies on
global state, and I believe that having a compatible implementation that
can eliminate this is a good option.
If PHP supports some parallel implementation in the future, and
`mt_srand()` and `mt_rand()` are deprecated, it may be useful as an
alternative method.
> You should probably mention that the classes can be serialized in the
RFC.
I had forgotten about this one. I've added it. Thanks.
> Naming
I think this needs to be discussed further.
The name RNG\RNGInterface is a compromise at this point, and is mainly
based on the PSR conventions. However, PSR is only a userland convention
and I am not sure if the core should take this into account.
However, we also believe that the name is easy to understand, although it
is somewhat redundant.
> 64-bit
I've been thinking for a while about what to do since then, and I think
your suggestion is probably the most appropriate.
That is, remove the `RNG64Interface` and the `next64()` method, and use the
`rng_range()` function to generate random numbers beyond 32 bits.
However, there is a concern. RNG implementations will no longer be able to
return native 64-bit random numbers for seed values.
Given the class name `XorShift128Plus` , users might expect to return the
number `6233086606872742541` when `12345` is the seed value.
On the other hand, it is possible to pseudo-generate 64-bit random numbers
by bit-shifting even for 32-bit RNGs.
I thought of using this to include `next64()` in the `RNGInterface` itself,
but then the problem of userland implementation comes into play.
Originally, the `next64()` method should always throw an exception if
`PHP_INT_SIZE >= 8`, but if you allow userland implementation, it is
implementation dependent.
To solve these problems, how about adding a function like the following? It
doesn't seem like a very good idea, but...
`rng_next(RNG\RNGInterface $rng, bool $unsigned = true): int`
`rng_next64(RNG\RNGInterface $rng, bool $unsigned = true): int`
These will do a bit shift and return an unsigned integer if `$unsigned` is
true. Otherwise, they return the value as generated by the RNG.
Of course, if `rng_next64()` is called in a 32bit environment, it will
throw a `ValueError` exception.
In this case, however, the interface is no longer an interface. Perhaps it
should be an abstract class, like this
```php
abstract class AbstractRNG
{
abstract protected function next(): int;
abstract protected function next64(): int;
}
```
It may also be useful to have a trait like this
```php
trait RNG64Support
{
abstract function next(): int;
protected function next64(): int
{
$ret = $this->next();
return $ret << 32 | $this->ret();
}
}
```
It's pretty "exotic" for a core implementation. :o
Does anyone have any good ideas?
After all this time, I'm not good at English, and I apologize if this is
inappropriate.
Regards,
Go Kudo
2021年1月20日(水) 1:19 Nikita Popov <nikita.ppv@gmail.com>:
