September 6, 2021 02:firstname.lastname@example.org (Pierre Joye)
On Mon, Sep 6, 2021, 12:40 AM Ben Ramsey <email@example.com> 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.
> 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.
I tend to agree with you. However, the same logic applies to any non binary
bytes RNG, all of them derivate from there with constraints.
I suppose this is choice PHP has to take. I don't see such APIs changing
too much over time but maybe in the beginning. It could be done in two