Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113049
MIME-Version: 1.0
References: <CABTDVhCtBn7T0YyB+55Mxxz1UCYi7ov_Se2nX-Uxh3EmK4XkdA@mail.gmail.com>
 <CABTDVhC7f4B9eB5dd9avMNQvt9iNtKy6EyqpRJDZmhckyr48Lw@mail.gmail.com> <CAAwdEzAue3SAALTR3TPa0XipVy-pqtM2YXdc4+BjURYJhDQc4g@mail.gmail.com>
In-Reply-To: <CAAwdEzAue3SAALTR3TPa0XipVy-pqtM2YXdc4+BjURYJhDQc4g@mail.gmail.com>
Date: Tue, 2 Feb 2021 21:42:07 +0900
Message-ID: <CABTDVhCF1fQP_X68MRNd0aOFaiJ=v1Qy6wU2VjCDNgw2=GqHNg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000010ba6e05ba59cde4"
Subject: Re: [PHP-DEV] Re: [RFC] Object-scope RNG implementation
From: zeriyoshi@gmail.com (Go Kudo)

--00000000000010ba6e05ba59cde4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=3D1610185985

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 =3D 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=E5=B9=B41=E6=9C=8827=E6=97=A5(=E6=B0=B4) 22:24 Alexandru P=C4=83tr=C4=
=83nescu <drealecs@gmail.com>:

>
> On Tue, Jan 26, 2021 at 8:06 PM Go Kudo <zeriyoshi@gmail.com> 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 i=
n
>> more detail and the execution speed has been re-verified with PHP 8.1-de=
v.
>>
>> 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=E5=B9=B41=E6=9C=889=E6=97=A5(=E5=9C=9F) 19:00 Go Kudo <zeriyoshi@gm=
ail.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
>> >
>>
>
> 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 meth=
od
> 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 als=
o
> 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
>
>

--00000000000010ba6e05ba59cde4--