Re: [PHP-DEV] Re: [RFC] Random Extension 3.0

  115952
September 5, 2021 04:00 zeriyoshi@gmail.com (Go Kudo)
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年9月5日(日) 1:12 Ben Ramsey <ramsey@php.net>:
> 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 > >
  115957
September 5, 2021 17:40 ramsey@php.net (Ben Ramsey)
--yeCRee4FrvVFZPeXZmmvsykLtAWHgO0jF
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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. >=20 > Do we still need an RFC in this case? I'm not sure I'm not fully unders= tand
> the criteria for an RFC. Does this internal API change count as a BC Br= eak
> 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 c= ore.
>=20 > 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 w= ould
> 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. Cheers, Ben --yeCRee4FrvVFZPeXZmmvsykLtAWHgO0jF--