Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115959
MIME-Version: 1.0
References: <CABTDVhBRpD=nWBk2xGLEmdcWwOzCeqGeqH5vLSugPFOeEN9Mog@mail.gmail.com>
 <61339ad1.1c69fb81.b518e.8644SMTPIN_ADDED_MISSING@mx.google.com>
 <CABTDVhC9d7R0czB5mUhfcUOc--E4xe+9V2W9dWLS7oYe_5fpNA@mail.gmail.com> <61350112.1c69fb81.82294.dff2SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <61350112.1c69fb81.82294.dff2SMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 6 Sep 2021 10:06:17 +0200
Message-ID: <CAF+90c95MGGyQqDRU7w=e5fe3FkFtF202ho4sKCcBgV0-gcApg@mail.gmail.com>
To: Ben Ramsey <ramsey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a4e1db05cb4f2096"
Subject: Re: [PHP-DEV] Re: [RFC] Random Extension 3.0
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a4e1db05cb4f2096
Content-Type: text/plain; charset="UTF-8"

On Sun, Sep 5, 2021 at 7:40 PM Ben Ramsey <ramsey@php.net> wrote:

> Go Kudo wrote on 9/4/21 23:00:
> > Indeed, it may be true that these suggestions should not be made all at
> > once. If necessary, I would like to propose to organize the RNG
> > implementation first.
> >
> > Do we still need an RFC in this case? I'm not sure I'm not fully
> understand
> > the criteria for an RFC. Does this internal API change count as a BC
> Break
> > that requires an RFC?
>
> Yes, since re-organizing the RNG implementation is a major language
> change that affects extensions and other downstream projects, this
> requires an RFC.
>
> >> Personally, I don't see the benefit of including this OOP API in the
> core.
> >
> > On the other hand, can you tell me why you thought it was unnecessary?
> > Was my example unrealistic?
>
> You also said, in reply to Dan Ackroyd:
>
> > Either way, I'll try to separate these suggestions if necessary, but if
> we
> > were to try to provide an OOP API without BC Break, what do you think
> would
> > be the ideal form?
>
> The OOP API appears to be a wrapper around the RNG functions. The only
> thing it gains by being in the core is widespread use, but it loses a
> lot of flexibility and maintainability, since the API will be tied to
> PHP release cycles.
>
> By doing this as an OOP wrapper in userland code, you're not restricting
> yourself to release only when PHP releases, and you can work with the
> community (e.g., the PHP-FIG) to develop interfaces that other projects
> might use so they can make use of their own RNGs, etc.
>

The OO API is not just a wrapper around the RNG functions -- it provides
new functionality that cannot be efficiently implemented in userland code.
This is for two reasons:

1. It provides independent randomness streams, which means it's not
possible to reuse existing functionality like mt_rand() for this purpose,
which only provides a single global random number stream. You would have to
reimplement the random number generator in userland. While this is
possible, it will generally not be efficient, because PHP does not have
native support for unsigned modular arithmetic, which is what random number
generators generally need.

2. It allows using functions like shuffle() and array_rand() with an
independent randomness stream. These functions cannot be efficiently
implemented in userland, because userland does not have random access to
arrays. Internals can generate a random number and use it to pick the key
at that position, which is O(1). Userland would have to call array_keys()
first to allow random access on keys, which is O(n).

Which is why I think this is a good addition to php-src. There's three good
reasons to include functionality in php-src (performance, ubiquity and FFI)
and this falls squarely into the first category. And now that we have
fibers and need to worry more about multiple independent execution streams,
we also need to worry about multiple independent randomness streams.

Regards,
Nikita

--000000000000a4e1db05cb4f2096--