Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113932
MIME-Version: 1.0
References: <CABTDVhD+gK9rqSceDa0Ct7OcsgT5E6+Lb_nX_gCfzq-oZnNpxw@mail.gmail.com>
 <CAAKU0ukOpZfx0zUfzMsMLutbSZXVg+fXYZvZsGJwjv7qc9OLnA@mail.gmail.com>
 <CABTDVhCK+3BuLiLg-SjsM3kuCoA7L_GnJVptKMjLEYeiyh6AMA@mail.gmail.com> <CAGBsUrd-tnMLYxNxqt89ZbNjPX7pdmZTZgiRc_Ht9G6EBqGYAw@mail.gmail.com>
In-Reply-To: <CAGBsUrd-tnMLYxNxqt89ZbNjPX7pdmZTZgiRc_Ht9G6EBqGYAw@mail.gmail.com>
Date: Sat, 3 Apr 2021 00:12:31 +0200
Message-ID: <CADyq6s+ybNnV6mmH0NRC8+6JuHkMQa6MrevQebRuRGzMc27S1g@mail.gmail.com>
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: Go Kudo <zeriyoshi@gmail.com>, Levi Morrison <levi.morrison@datadoghq.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a6a7c305bf04a576"
Subject: Re: [PHP-DEV] [VOTE] Object scoped RNG implementation
From: ocramius@gmail.com (Marco Pivetta)

--000000000000a6a7c305bf04a576
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 2, 2021, 23:56 Kamil Tekiela <tekiela246@gmail.com> wrote:

> Hi Go Kudo,
>
> First, let me say that I believe we need such implementation in PHP and I
> would like to see object scoped RNG as part of the standard. However, I
> have voted no for a number of reasons. Let me list them from the
> perspective of a noob PHP user.
>
> - I really do not understand why we are introducing new functions. Can't
> the classes implement the necessary methods to get integers, doubles, and
> string of bytes? As a new user I would be completely overwhelmed by all
> these functions: rand(), mt_rand(), rng_int(), rng_next(), rng_next64().
> Which one should I use? What is the difference between rng_next()
> and rng_next64?
> - As soon as I left the RFC page I forgot what the new classes were called.
> I still can't tell from memory what's their name. I understand what they
> mean, but they are definitely not friendly names.
> - What's the difference between MT19937 and XorShift128Plus? They are
> different algorithms but which one should I pick? I tested the
> implementation locally and I see no difference in performance.
> - I am not a fan of adding a new optional parameter to shuffle() and
> friends. I'd prefer to have a method in the class that I can pass an array
> to.
> - What is the default seed? Do I have to provide a seed each time? Why
> can't the seed be done automatically?
> - Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers.
> What's the real-life purpose of this flag?
> - I don't see any use in supporting userland implementations. Why can't
> they create separate libraries?  I don't know about performance, but if
> someone wants to have custom RNG then I don't think they worry about
> performance.
> - When using the functions the performance was 50% worse than when calling
> ->next() directly. Is this right or is the implementation going to be
> optimized further? The fastest way to get a random number seems to be
> mt_rand() based on my tests.
>
> I would rather like to see a single class called RNG/Random that implements
> RNG/RandomInterface. The constructor of the class would take 2 arguments.
> The first is the algorithm with a default either MT or XORShift. The second
> is an optional seed. If no seed is provided then the seed is generated
> automatically like in mt_srand(). The class would then implement methods
> like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(),
> stringShuffle(), randomArrayKeys(). I would keep the standard functions as
> they are. Let them use MT by default. We could even deprecate them in
> future if this takes off.
>
> This would make it painfully obvious what the class does and how to use it.
> No more procedural code. I would also make the class final so that you
> can't inherit from it, but that is highly opinion-based.
> Now that I have written this, I read previous conversations and it looks to
> me like what I would like is what you had previously.
>
> I'm sorry if I complain too much, but I would like to see something like
> this implemented, just not like you are proposing right now. It is too
> messy for me and I know I wouldn't like it if I had to use it.
>

Changed my vote to "no" after this in-detail review.

Overall, I was conflicted, and voted "yes" especially because we do really
need a better and reproducible seeding solution for RNG, and the current
API is insufficient.

The API proposed so far is quite terrible though, and if the vote passed,
we'd have to stick with it for an infinity of years.

>

--000000000000a6a7c305bf04a576--