Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115952
MIME-Version: 1.0
References: <CABTDVhBRpD=nWBk2xGLEmdcWwOzCeqGeqH5vLSugPFOeEN9Mog@mail.gmail.com>
 <61339ad1.1c69fb81.b518e.8644SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <61339ad1.1c69fb81.b518e.8644SMTPIN_ADDED_MISSING@mx.google.com>
Date: Sun, 5 Sep 2021 13:00:04 +0900
Message-ID: <CABTDVhC9d7R0czB5mUhfcUOc--E4xe+9V2W9dWLS7oYe_5fpNA@mail.gmail.com>
To: Ben Ramsey <ramsey@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eda8bb05cb37917b"
Subject: Re: [PHP-DEV] Re: [RFC] Random Extension 3.0
From: zeriyoshi@gmail.com (Go Kudo)

--000000000000eda8bb05cb37917b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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?

> 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?

I'm sorry if my English is not good and my writing seems offensive. I have
no intention to do so.

Regards,
Go Kudo

2021=E5=B9=B49=E6=9C=885=E6=97=A5(=E6=97=A5) 1:12 Ben Ramsey <ramsey@php.ne=
t>:

> Go Kudo wrote on 9/2/21 10:10:
> > Hi Internals.
> >
> > Expanded from the previous RFC and changed it to an RFC that organizes
> the
> > whole PHP random number generator. Also, the target version has been
> > changed to 8.2.
> >
> > https://wiki.php.net/rfc/rng_extension
> > https://github.com/php/php-src/pull/7453
> >
> > Hopefully you will get some good responses.
> >
> > Regards,
> > Go Kudo
> >
>
>
> This proposal seems like two different proposals to me:
>
> - The first consolidates and cleans up RNG functions for internals
> - The second exposes an OOP API for working with RNGs
>
> Personally, I don't see the benefit of including this OOP API in the
> core. I don't think it provides any benefits over similar abstractions
> in userland, and in fact, I think this kind of API is best suited for
> iteration in userland.
>
> Cheers,
> Ben
>
>

--000000000000eda8bb05cb37917b--