Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
Hi Alex
First, let me apologize for my poor English skills. It may contain rude
expressions, but it is not s intentional.
> The closest library I know and used when I had that need you mentioned is
a userland implementation: https://github.com/paragonie/RandomLib
This seems to be actively maintained, but is a fairly object-oriented-like
implementation.
> The library is organized nicely with a Generator class that depends on
constructor of a source for randomness.
This seems to be a more object-oriented implementation.
This RFC also initially proposed an object-oriented implementation, but due
to the redundancy of the implementation and interoperability issues with
existing code, it was changed to a procedural-based implementation. (But it
is not as elegant as this library.)
https://wiki.php.net/rfc/object_scope_prng?rev=1610185985
And perhaps, if we want to provide an object-oriented implementation, it
would be preferable to separate it into a new dedicated module instead of a
standard module. Currently, it is implemented in the standard module for
the convenience of modifying existing functions.
Is this what you envision the whole thing to look like in the end?
```php
final class RandomGenerator
{
public function __constrct(RandomSourceInterface $source): void {}
public function randomInt(int $min, int $max): int {}
public function randomFloat(): float {}
public function randomBytes(int $size): string {}
public function randomString(int $size, string $characters): striing {}
// compatibility for some functions.
public function arrayShuffle(array &$array): bool {}
public function stringShuffle(string $string): string {}
public function arrayRandom(array $array, int $num = 1):
int|string|array {}
}
interface RandomSourceInterface
{
public function getBytes(int $size): string;
}
class RandomXorShift128PlusSource implements RandomSourceInterface {}
class RandomMT19937Source implements RandomSourceInterface {}
class RandomLibsodiumSource implements RandomSourceInterface {}
class SecureOsSpecificSource implements RandomSourceInterface {}
```
While this is certainly an appropriate object-oriented implementation, it
raises the following concerns.
- This implementation is much more complex than the PHP built-in random
number generator implementation.
Probably, many users will continue to use `mt_srand()` / `mt_rand()` in the
future. This can lead to dangerous implementations that rely on global
state.
This RFC does not go that far, but we are considering deprecating
`mt_srand()` and `mt_rand()` in the future (much further down the road).
In order to achieve this, I believe it is necessary to implement it in a
way that does not compromise usability.
- There are interoperability problems with existing functions.
It is difficult to notice that `shuffle()`, `str_shuffle()`, and
`array_rand()` rely on dangerous internal MT states, and it becomes
difficult to fix them.
I hope this RFC will move forward. Thanks for your input.
Regards,
Go Kudo
2021年1月27日(水) 22:24 Alexandru Pătrănescu :
>
> On Tue, Jan 26, 2021 at 8:06 PM Go Kudo wrote:
>
>> RFCs have been reorganized and radically rewritten.
>> https://wiki.php.net/rfc/object_scope_prng
>>
>> The implementation is unchanged, but the background has been explained in
>> more detail and the execution speed has been re-verified with PHP 8.1-dev.
>>
>> The proposal seems to have been received relatively positively by
>> externals, but there hasn't been much reaction. I'm unsure when I should
>> start voting on this RFC.
>>
>> Regards,
>> Go Kudo
>>
>> 2021年1月9日(土) 19:00 Go Kudo :
>>
>> > 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
>> >
>>
>
> Hi Go Kudo,
>
> The closest library I know and used when I had that need you mentioned is
> a userland implementation: https://github.com/paragonie/RandomLib,
> created by Anthony Ferrara and not maintained by Paragon Initiative
> Enterprises.
> The library is organized nicely with a Generator class that depends on
> constructor of a source for randomness. The source has just a simple method
> to obtain a specific number of bytes and that's all.
>
> I think the naming is what needs more input here. I'm thinking we can also
> have:
> - a random bytes source/generator that can be very similar with what you
> propose: an interface, multiple internal classes, allowing userland extra
> classes.
> - a random generator class that would have multiple useful methods like:
> randomInt($min, $max), randomFloat(), randomBytes($size),
> randomString($size, $possibleCharacters) etc.
>
> As for namings, calling them
> - RandomGenerator final class that accepts at constructor a
> - RandomSource interface with one method getBytes($size) implemented by
>
Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
On Tue, Jan 26, 2021 at 8:06 PM Go Kudo wrote: > RFCs have been reorganized and radically rewritten. > https://wiki.php.net/rfc/object_scope_prng > > The implementation is unchanged, but the background has been explained in > more detail and the execution speed has been re-verified with PHP 8.1-dev. > > The proposal seems to have been received relatively positively by > externals, but there hasn't been much reaction. I'm unsure when I should > start voting on this RFC. > > Regards, > Go Kudo > > 2021年1月9日(土) 19:00 Go Kudo : > > > 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 > > > Hi Go Kudo, The closest library I know and used when I had that need you mentioned is a userland implementation: https://github.com/paragonie/RandomLib, created by Anthony Ferrara and not maintained by Paragon Initiative Enterprises. The library is organized nicely with a Generator class that depends on constructor of a source for randomness. The source has just a simple method to obtain a specific number of bytes and that's all. I think the naming is what needs more input here. I'm thinking we can also have: - a random bytes source/generator that can be very similar with what you propose: an interface, multiple internal classes, allowing userland extra classes. - a random generator class that would have multiple useful methods like: randomInt($min, $max), randomFloat(), randomBytes($size), randomString($size, $possibleCharacters) etc. As for namings, calling them - RandomGenerator final class that accepts at constructor a - RandomSource interface with one method getBytes($size) implemented by RandomXorShift128PlusSource, RandomMT19937Source, RandomLibsodiumSource, SecureOsSpecificSource etc. is a quick idea from me. State, when is the case, sits in the random source object and can be of course serialized. Other than this, initiative looks good. I apologize if I provided the feedback a bit late. Regards, Alex
[PHP-DEV] Re: [RFC] Object-scope RNG implementation
RFCs have been reorganized and radically rewritten. https://wiki.php.net/rfc/object_scope_prng The implementation is unchanged, but the background has been explained in more detail and the execution speed has been re-verified with PHP 8.1-dev. The proposal seems to have been received relatively positively by externals, but there hasn't been much reaction. I'm unsure when I should start voting on this RFC. Regards, Go Kudo 2021年1月9日(土) 19:00 Go Kudo : > 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 >
[PHP-DEV] Re: [RFC] Object-scope RNG implementation
Hi internals.
RFC has been updated to 1.3 and implemented.
https://wiki.php.net/rfc/object_scope_prng
The main changes are as follows:
- `RNG\OSRNG` has been renamed to `RNG\OS`. This was too verbose.
- `rng_rand()` has been renamed to `rng_int()` and the arguments `$min`
and `$max` are now required.
- `RNG\RNG64Interface` has been removed and `next64()` is now included in
`RNGInterface`.
- PHP code does not depend on the size of int. Even if it contains a
64-bit implementation, it will work fine on 32-bit PHP. Libraries should
always consider the 64-bit environment.
- To solve various problems, the `rng_next()` and `rng_next64()`
functions have been added.
- `rng_next64()` throws a `ValueError` exception when called in a 32bit
environment.
The current phpstub is as follows:
```php
function shuffle(array &$array, ?RNG\RNGInterface $rng = null): bool {}
function str_shuffle(string $string, ?RNG\RNGInterface $rng = null): string
{}
function array_rand(array $array, int $num = 1, ?RNG\RNGInterface $rng =
null): int|string|array {}
function rng_bytes(RNG\RNGInterface $rng, int $length): string {}
function rng_int(RNG\RNGInterface $rng, int $min, int $max): int {}
function rng_next(RNG\RNGInterface $rng, bool $unsigned = true): int {}
/** @throws ValueError */
function rng_next64(RNG\RNGInterface $rng, bool $unsigned = true): int {}
```
On the other hand, there are still the following problems
- If `next64()` method is called directly in a 32-bit environment, it will
produce unintended results.
- This can be avoided by using `rng_next64()` in RFC 1.3. As with the
various internal interfaces, direct method calls can be deprecated.
- Namespace. `RNG`, `PHP\RNG`... etc
- Interface naming. `RNGInterface` may be a bit redundant.
`NumberGenerator`, etc?
We are looking for feedback on these problems.
Regards,
Go Kudo
2021年1月9日(土) 19:00 Go Kudo :
> 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
>
Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
> 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 :
> On Mon, Jan 18, 2021 at 5:29 PM Go Kudo wrote:
>
>> RFC and implementation updated.
>>
>> https://wiki.php.net/rfc/object_scope_prng
>> https://github.com/php/php-src/pull/6568
>>
>> > MT19937 returns a signed 32bit number as a result of the `next()`
>> method;
>> the mt_rand() function returns a bit-shifted unsigned 31bit number, so the
>> results are not identical.
>>
>> The `rng_range()` function has been renamed to `rng_rand()` and returns an
>> unsigned 31-bit integer like the `mt_rand()` function if only the $rng
>> argument is received.
>>
>> ```php
>> mt_srand(1234);
>> mt_rand() === rng_rand(new \RNG\MT19937(1234)); // true
>> ```
>>
>> This allows to completely replace the `mt_rand()` function with the
>> RNG\MT19937.
>>
>> I said I wanted to initiate a vote, but there seems to be too much
>> discussion missing for that.
>> I'd like to wait and see for a while.
>>
>> Regards,
>> Go Kudo
>>
>> 2021年1月17日(日) 20:02 Go Kudo :
>>
>> > Updated the RFC and fixed the implementation.
>> > Also made some additions to the RFC about when this feature might be
>> > useful.
>> >
>> > RFC: https://wiki.php.net/rfc/object_scope_prng
>> > Implementation PR: https://github.com/php/php-src/pull/6568 (All CI
>> > passed)
>> >
>> > The main points are as follows:
>> >
>> > - The implementation now meets all requirements. (maybe)
>> > - Implemented MT19937, which is compatible with PHP standard MT. The
>> > consistency of these is ensured by tests.
>> > - The implementation is now what we used to call TypeII.
>> > - All RNG implementations can now be inherited like regular classes. Use
>> > faster calls only if the class is an internal class.
>> > - The implementation has been heavily modified and the quality of the
>> code
>> > has been improved.
>> >
>> > Currently, there are a few concerns:
>> >
>> > -
Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
Am 19.01.21, 17:20 schrieb "Nikita Popov" : * 64-bit: I looked over your implementation, and I think your approach to handling 64-bits is correct. You only call next64() if the requested range is larger than 32-bit, and that can only happen on 64-bit systems, thus guaranteeing consistency of results (where they can be consistent at all). What I'm unsure about is the way this gets exposed to userland via next() and next64() methods. I think fetching of 64-bit values is mainly interesting as an internal optimization, and not so much important to be part of the RNGInterface API. The user is intended to get numbers via rng_rand(), not by directly calling next(). A possibility here would be to drop the RNG64Interface and next64() method, have next() always return 32-bit, but retain the internal next64 API. For this to make sense, we'd need two subsequent internal next() calls to return the same data as a single next64() call (i.e. store the result and first return one half then the other). Would this make sense to you? Wouldn't it make more sense to provide different classes for the algorithm instead of two next/64 methods or limiting it? Like: * class MT19937(system depending) * class MT19937_32 (32bit version) * class MT19937_64 (64bit version - not available on 32bit) This way the user can take the algorithm that matches best his requirements. Marc Regards, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
Yes. RNG stands for Random Number Generator, which I think is a common acronym. Cryptographic pseudo-random number generators are commonly known as a CSPRNG. 2021年1月19日(火) 1:42 Kamil Tekiela : > What does rng stand for? Is it short for range or acronym of random number > generator? >
Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
On Mon, Jan 18, 2021 at 5:29 PM Go Kudo wrote: > RFC and implementation updated. > > https://wiki.php.net/rfc/object_scope_prng > https://github.com/php/php-src/pull/6568 > > > MT19937 returns a signed 32bit number as a result of the `next()` method; > the mt_rand() function returns a bit-shifted unsigned 31bit number, so the > results are not identical. > > The `rng_range()` function has been renamed to `rng_rand()` and returns an > unsigned 31-bit integer like the `mt_rand()` function if only the $rng > argument is received. > > ```php > mt_srand(1234); > mt_rand() === rng_rand(new \RNG\MT19937(1234)); // true > ``` > > This allows to completely replace the `mt_rand()` function with the > RNG\MT19937. > > I said I wanted to initiate a vote, but there seems to be too much > discussion missing for that. > I'd like to wait and see for a while. > > Regards, > Go Kudo > > 2021年1月17日(日) 20:02 Go Kudo : > > > Updated the RFC and fixed the implementation. > > Also made some additions to the RFC about when this feature might be > > useful. > > > > RFC: https://wiki.php.net/rfc/object_scope_prng > > Implementation PR: https://github.com/php/php-src/pull/6568 (All CI > > passed) > > > > The main points are as follows: > > > > - The implementation now meets all requirements. (maybe) > > - Implemented MT19937, which is compatible with PHP standard MT. The > > consistency of these is ensured by tests. > > - The implementation is now what we used to call TypeII. > > - All RNG implementations can now be inherited like regular classes. Use > > faster calls only if the class is an internal class. > > - The implementation has been heavily modified and the quality of the > code > > has been improved. > > > > Currently, there are a few concerns: > > > > - MT19937 returns a signed 32bit number as a result of the `next()` > > method; the mt_rand() function returns a bit-shifted unsigned 31bit > number, > > so the results are not identical. > > - You can get the equivalent result with `$rng->next() << 1 & > > PHP_INT_MAX`, but maybe you should have a `nextUnsigned31()` method. > > - Currently, the test uses `$rng->next() << 1 & PHP_INT_MAX`. > > - The implementation of MT19937 is redundant. This can be merged. > > > > Anyway, I think the code is finally ready for review. > > Once that is done, we will start voting on RFCs. > > > > Regards, > > Go Kudo > Overall I like the proposal. Some notes: * I know you only just changed it, 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. * You should probably mention that the classes can be serialized in the RFC. Maybe you want to write out all the methods so it's also visible how the constructors for the classes look like. * Naming: RNG\RNGInterface seems a bit redundant. Of course, we can't make it RNG\Interface. RNG\Generator would be an option. I'm not sure about this. Maybe RNG\RNGInterface is fine. * 64-bit: I looked over your implementation, and I think your approach to handling 64-bits is correct. You only call next64() if the requested range is larger than 32-bit, and that can only happen on 64-bit systems, thus guaranteeing consistency of results (where they can be consistent at all). What I'm unsure about is the way this gets exposed to userland via next() and next64() methods. I think fetching of 64-bit values is mainly interesting as an internal optimization, and not so much important to be part of the RNGInterface API. The user is intended to get numbers via rng_rand(), not by directly calling next(). A possibility here would be to drop the RNG64Interface and next64() method, have next() always return 32-bit, but retain the internal next64 API. For this to make sense, we'd need two subsequent internal next() calls to return the same data as a single next64() call (i.e. store the result and first return one half then the other). Would this make sense to you? Regards, Nikita
Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
What does rng stand for? Is it short for range or acronym of random number generator?
[PHP-DEV] Re: [RFC] Object-scope RNG implementation
RFC and implementation updated. https://wiki.php.net/rfc/object_scope_prng https://github.com/php/php-src/pull/6568 > MT19937 returns a signed 32bit number as a result of the `next()` method; the mt_rand() function returns a bit-shifted unsigned 31bit number, so the results are not identical. The `rng_range()` function has been renamed to `rng_rand()` and returns an unsigned 31-bit integer like the `mt_rand()` function if only the $rng argument is received. ```php mt_srand(1234); mt_rand() === rng_rand(new \RNG\MT19937(1234)); // true ``` This allows to completely replace the `mt_rand()` function with the RNG\MT19937. I said I wanted to initiate a vote, but there seems to be too much discussion missing for that. I'd like to wait and see for a while. Regards, Go Kudo 2021年1月17日(日) 20:02 Go Kudo : > Updated the RFC and fixed the implementation. > Also made some additions to the RFC about when this feature might be > useful. > > RFC: https://wiki.php.net/rfc/object_scope_prng > Implementation PR: https://github.com/php/php-src/pull/6568 (All CI > passed) > > The main points are as follows: > > - The implementation now meets all requirements. (maybe) > - Implemented MT19937, which is compatible with PHP standard MT. The > consistency of these is ensured by tests. > - The implementation is now what we used to call TypeII. > - All RNG implementations can now be inherited like regular classes. Use > faster calls only if the class is an internal class. > - The implementation has been heavily modified and the quality of the code > has been improved. > > Currently, there are a few concerns: > > - MT19937 returns a signed 32bit number as a result of the `next()` > method; the mt_rand() function returns a bit-shifted unsigned 31bit number, > so the results are not identical. > - You can get the equivalent result with `$rng->next() << 1 & > PHP_INT_MAX`, but maybe you should have a `nextUnsigned31()` method. > - Currently, the test uses `$rng->next() << 1 & PHP_INT_MAX`. > - The implementation of MT19937 is redundant. This can be merged. > > Anyway, I think the code is finally ready for review. > Once that is done, we will start voting on RFCs. > > Regards, > Go Kudo > > 2021年1月9日(土) 19:00 Go Kudo : > >> 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 >> >
[PHP-DEV] Re: [RFC] Object-scope RNG implementation
Updated the RFC and fixed the implementation. Also made some additions to the RFC about when this feature might be useful. RFC: https://wiki.php.net/rfc/object_scope_prng Implementation PR: https://github.com/php/php-src/pull/6568 (All CI passed) The main points are as follows: - The implementation now meets all requirements. (maybe) - Implemented MT19937, which is compatible with PHP standard MT. The consistency of these is ensured by tests. - The implementation is now what we used to call TypeII. - All RNG implementations can now be inherited like regular classes. Use faster calls only if the class is an internal class. - The implementation has been heavily modified and the quality of the code has been improved. Currently, there are a few concerns: - MT19937 returns a signed 32bit number as a result of the `next()` method; the mt_rand() function returns a bit-shifted unsigned 31bit number, so the results are not identical. - You can get the equivalent result with `$rng->next() << 1 & PHP_INT_MAX`, but maybe you should have a `nextUnsigned31()` method. - Currently, the test uses `$rng->next() << 1 & PHP_INT_MAX`. - The implementation of MT19937 is redundant. This can be merged. Anyway, I think the code is finally ready for review. Once that is done, we will start voting on RFCs. Regards, Go Kudo 2021年1月9日(土) 19:00 Go Kudo : > 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 >
[PHP-DEV] Re: [RFC] Object-scope RNG implementation
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 : > 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 >
[PHP-DEV] Re: [RFC] Object-scope RNG implementation
Hi internals.
I implemented Type II, which was pointed out by Nikita and fixed.
https://github.com/zeriyoshi/php-src/commit/5ff8882a8fbfaf4ffd5cc42fb5853c4a1a00c182
This is much smarter and simpler than Type I, but the implementation is
more complex (partly due to my lack of knowledge).
It contains the complete implementation except for MT19937, and the
userland implementation and the native implementation are completely
separated internally. In other words, cannot inherit from native classes.
Also, I found during the implementation that the array_rand() function can
get stuck if you implement an RNG that always returns a fixed result, for
example.
```
class FixedNumberGenerator implements \RNG\RNGInterface
{
public function next(): int
{
return 1;
}
public function next64(): int
{
return 2;
}
}
$rng = new FixedNumberGenerator();
$array = range(1, 100);
array_rand($array, 2, $rng); // Oops, stucked.
```
This can be somewhat dangerous and should be kept in mind when implementing
it.
There has been no positive or negative feedback on this suggestion, and
frankly I am worried that I am continuing to act in an unpleasant manner.
Regards,
Go Kudo
2021年1月9日(土) 19:00 Go Kudo :
> 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
>
