Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113938 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87738 invoked from network); 3 Apr 2021 18:51:31 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Apr 2021 18:51:31 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 50CD21804D8 for ; Sat, 3 Apr 2021 11:49:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mercury.negativeion.net (mercury.negativeion.net [199.38.81.6]) by php-smtp4.php.net (Postfix) with ESMTP for ; Sat, 3 Apr 2021 11:49:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.negativeion.net (Postfix) with ESMTP id 0FBB120D0AC992 for ; Sat, 3 Apr 2021 14:49:50 -0400 (EDT) Received: from mercury.negativeion.net ([127.0.0.1]) by localhost (mercury.negativeion.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kejEV9Fp1e3a for ; Sat, 3 Apr 2021 14:49:49 -0400 (EDT) Received: from [10.0.1.101] (unknown [173.225.146.47]) by mercury.negativeion.net (Postfix) with ESMTPSA id ECB9720D0AC980 for ; Sat, 3 Apr 2021 14:49:48 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 3 Apr 2021 13:49:48 -0500 References: <981a25de-e61c-4703-9be1-fd03b0409245@www.fastmail.com> To: php internals In-Reply-To: <981a25de-e61c-4703-9be1-fd03b0409245@www.fastmail.com> Message-ID: <309419D6-E342-4C5A-B5C2-77568F9D2ED4@trowski.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [PHP-DEV] [VOTE] Object scoped RNG implementation From: aaron@trowski.com (Aaron Piotrowski) > On Apr 2, 2021, at 5:49 PM, Larry Garfield = wrote: >=20 > On Fri, Apr 2, 2021, at 4:56 PM, Kamil Tekiela wrote: >> Hi Go Kudo, >>=20 >> 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. >>=20 >> - 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Regards, >> Kamil >=20 > I also didn't pay close attention to the previous discussion, but = reading the RFC I agree with all of this. The functionality proposed is = good and needed, but the API is a mess. What Kamil suggests is far = better, and fully commits to being OOPy. Given that the use case is for = situations where you need a predictable and repeatable random sequence, = such as Fibers or threads or such, going all-in on an object seems like = the correct approach. >=20 > One thing I'm not 100% clear on from the RFC, does this also deprecate = random_int()/random_bytes()? Those are (AFAIK) unseeded, so they seem = like they'd continue to serve their current purpose, but it's not clear = from the RFC. >=20 > Voting no for now, but I would welcome a resubmission with a cleaner = API, even in this cycle. >=20 > --Larry Garfield >=20 I too voted no for similar reasons as Larry, Marco, Levi, and others. = The API needs improvement and using a new namespace without precedent or = a plan is problematic. Overall I=E2=80=99m in favor of an object-based approach and encourage = you to rework the API and bring it to a vote for PHP 8.1. Cheers, Aaron Piotrowski