Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115976
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>
 <CAF+90c95MGGyQqDRU7w=e5fe3FkFtF202ho4sKCcBgV0-gcApg@mail.gmail.com> <61364ec1.1c69fb81.3ef56.96dcSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <61364ec1.1c69fb81.3ef56.96dcSMTPIN_ADDED_MISSING@mx.google.com>
Date: Tue, 7 Sep 2021 05:33:14 +0900
Message-ID: <CABTDVhCPzNpfqnf4pZ9hV=wSjQUGE4LPou7Y_k=TCAq6f_SqVw@mail.gmail.com>
To: Ben Ramsey <ramsey@php.net>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009c1ff105cb598f16"
Subject: Re: [PHP-DEV] Re: [RFC] Random Extension 3.0
From: zeriyoshi@gmail.com (Go Kudo)

--0000000000009c1ff105cb598f16
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nikita, Thanks for the clarification.
That's exactly what I intended to do.

> can you update the RFC with more information about this functionality?

I understand. Organize them and reconstruct the RFC text.

I've also created an RFC about moving RNG-related functions from
ext/standard to ext/random. I would appreciate it if you could check it out=
.

https://wiki.php.net/rfc/random_ext

Regards,
Go Kudo

2021=E5=B9=B49=E6=9C=887=E6=97=A5(=E7=81=AB) 2:24 Ben Ramsey <ramsey@php.ne=
t>:

> Nikita Popov wrote on 9/6/21 03:06:
> > 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 restricti=
ng
> >> yourself to release only when PHP releases, and you can work with the
> >> community (e.g., the PHP-FIG) to develop interfaces that other project=
s
> >> 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 provide=
s
> > 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 purpos=
e,
> > which only provides a single global random number stream. You would hav=
e
> 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 t=
o
> > arrays. Internals can generate a random number and use it to pick the k=
ey
> > 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
> >
>
> Thanks for the clarification, Nikita.
>
> The RFC says, "The Random class is a utility class that provides
> functionality using random numbers." This led me to think it was a
> wrapper that did not introduce new functionality.
>
> I can't find any discussion in the RFC on the independent randomness
> streams provided by the OOP API. Go Kudo, can you update the RFC with
> more information about this functionality?
>
> Cheers,
> Ben
>
>

--0000000000009c1ff105cb598f16--