Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112564
MIME-Version: 1.0
References: <CABTDVhA-FvEXdS+A=T5bJnX5YxjseN+ko14GUOqnuA52-omiiw@mail.gmail.com>
 <CABTDVhCKu9hjspzs3vv7=9=4C=NhSD9+85e++RhY6wXUwXGc6A@mail.gmail.com>
 <1f319ee0-e5e2-3d5e-2b8c-4d3c073f98e6@gmx.de> <CABTDVhCY44bT=U489KueCV3309AuN+1zPjRcfSSMEvfcM9Yfkw@mail.gmail.com>
In-Reply-To: <CABTDVhCY44bT=U489KueCV3309AuN+1zPjRcfSSMEvfcM9Yfkw@mail.gmail.com>
Date: Sun, 20 Dec 2020 17:09:36 +0300
Message-ID: <CAGgaK7+YXrZg5LR6a_BFS=BGEPNj023JjS+wQpymas4H9zGBBQ@mail.gmail.com>
To: zeriyoshi <zeriyoshi@gmail.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e8ce8305b6e5e484"
Subject: Re: [PHP-DEV] Re: Improving PRNG implementation.
From: maxsem.wiki@gmail.com (Max Semenik)

--000000000000e8ce8305b6e5e484
Content-Type: text/plain; charset="UTF-8"

On Sun, Dec 20, 2020 at 6:45 AM zeriyoshi <zeriyoshi@gmail.com> wrote:

> Thanks cmb. I have created a first draft of an RFC. I think I've covered
> all the necessary requirements, but I'd like to know if there are any
> problems.
> https://wiki.php.net/rfc/object_scope_prng


A few IMHO comments:
* Namespaces are controversial. There were multiple discussions and RFCs
about introducing them for new functionality but nothing came out of it.
Still probably worth adding an option for \PHP\PRNG to the vote, or
something like that.
* The "Which set of PRNGs should be provided as standard?" vote seems vague
to me. Are you proposing to add only one algorithm? Why? Also, the adding
just interfaces option makes no sense because there's Composer for things
that don't require a C implementation.
* "One possible solution is to implement the PRNG in pure PHP. There is
actually a userland library [1], but it is not fast enough for PHP at the
moment. (However, this may be improved by JIT)" - this definitely needs a
comparison because implementation in C is only needed for performance
reasons.
* Method names: you don't need to emulate the conventions from non-OOP
code, e.g. string_shuffle() --> strShuffle and array_rand() -->
arrayRand(). Use a more naturally readable convention like shuffleString().
* The return value in "function shuffle(array &$array): bool" means that if
something goes wrong, callers will have no idea what it is. Just throw an
exception.
* If the classes are namespaced, don't prefix their names,
e.g. PRNGInterface --> RandomGenerator (yay, so many opportunities for
bikeshedding!)
* Perhaps it's worth mentioning other languages using this pattern, e.g.
Java[1] and C#[2].
* Do you have evidence of widespread demand for this functionality? Usage
statistics for the userland implementation you mentioned[3] don't look that
hot.

------
[1] https://docs.oracle.com/javase/8/docs/api/java/util/Random.html
[2] https://docs.microsoft.com/en-us/dotnet/api/system.random?view=net-5.0
[3] https://packagist.org/packages/savvot/random

--000000000000e8ce8305b6e5e484--