# Discussion: Object-scoped RNG

- Thread: https://externals.io/message/114378
- Original archive: https://news-web.php.net/php.internals/114378
- Started by Go Kudo on 2021-05-11T12:57:42+00:00
- Messages: 12
- RFC: Object scoped RNG Implementations (Declined) — https://externals.io/rfc/object_scope_prng.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #114378 — Go Kudo — 2021-05-11T12:57:42+00:00

URL: https://externals.io/message/114378#114378

Hi internals.

I previously proposed an object scope RNG implementation inside.
However, the RFC was rejected after a vote.

https://wiki.php.net/rfc/object_scope_prng

Vote: https://externals.io/message/113888
Discussion: https://externals.io/message/112819

As per my previous proposal, PHP is currently in a very unclear state
regarding the random number implementation.

So I would like to ask a few questions.

- Do you think that PHP needs an object-scoped random number
implementation? And why?
- If the API in the previous RFC was improved and voted on again, would you
be willing to vote for it?
- What issues do you think should have been resolved between proposal and
ballot in the previous RFC?

I would like a variety of opinions.

Translated with www.DeepL.com/Translator (free version)

Regards,
Go Kudo

---

## #114421 — Levi Morrison via internals — 2021-05-11T19:46:12+00:00

URL: https://externals.io/message/114378#114421 · In reply to: #114378

>
> Hi internals.
>
> I previously proposed an object scope RNG implementation inside.
> However, the RFC was rejected after a vote.
>
> https://wiki.php.net/rfc/object_scope_prng
>
> Vote: https://externals.io/message/113888
> Discussion: https://externals.io/message/112819
>
> As per my previous proposal, PHP is currently in a very unclear state
> regarding the random number implementation.
>
> So I would like to ask a few questions.
>
> - Do you think that PHP needs an object-scoped random number
> implementation? And why?
> - If the API in the previous RFC was improved and voted on again, would you
> be willing to vote for it?
> - What issues do you think should have been resolved between proposal and
> ballot in the previous RFC?
>
> I would like a variety of opinions.
>
> Translated with www.DeepL.com/Translator (free version)
>
> Regards,
> Go Kudo

I would like to see an extension that doesn't contain the
backwards-compatibility breaking changes in the RFC. Every function,
type, and constant should be namespaced according to the extension.
For instance, if you want to call it `ext/rng`, then the namespace can
be `rng` or `Rng` or `RNG`.No exceptions for now! The previous
proposal had namespace things, and un-namespaced things, and breaking
changes, and I don't think that made a cohesive proposal.

Also, php-src generally doesn't suffix interfaces with the name
"Interface". Please provide another name for `RNGInterface`, like
`RandomNumberGenerator` or `RNG`.

---

## #114424 — Larry Garfield — 2021-05-11T21:20:59+00:00

URL: https://externals.io/message/114378#114424 · In reply to: #114378

> Hi internals.
> 
> I previously proposed an object scope RNG implementation inside.
> However, the RFC was rejected after a vote.
> 
> https://wiki.php.net/rfc/object_scope_prng
> 
> Vote: https://externals.io/message/113888
> Discussion: https://externals.io/message/112819
> 
> As per my previous proposal, PHP is currently in a very unclear state
> regarding the random number implementation.
> 
> So I would like to ask a few questions.
> 
> - Do you think that PHP needs an object-scoped random number
> implementation? And why?

I don't work in areas that would tend to need such a thing, but other people do so I have no objection to it existing, as long as it's well-designed.

> - If the API in the previous RFC was improved and voted on again, would you
> be willing to vote for it?

Yes.

> - What issues do you think should have been resolved between proposal and
> ballot in the previous RFC?
> 
> I would like a variety of opinions.

1) Get rid of all of the functions.  Object-scoped means... you just have an object with methods on it.  That's it.

2) Don't force people to use a subclass with an incomprehensible name.  In this case, a single class with a constructor parameter that specifies the algorithm to use is far superior.  Possibly that parameter could be an object conforming to an interface if you really want, as long as the default is reasonable so most people never have to use it.

3) Perhaps it should be named RandomSequence or similar?  It's not truly generating random numbers.  It's generating a repeatable but difficult to produce sequence off of a seed value.  That's not the same thing as `random_int()` et al.

So, at first pass, an API could be as simple as (pseudocode):

class RandomSequence {
  public function __construct(int $seed = `time()`, $algorithm = 'some_default') { ... }

  public function `next()`: int { ... }
}

And that's it.  That's nice and simple and predictable to use.

4) As Levi said, we have a new policy document on namespace usage.  This is a good first application of it.

--Larry Garfield

---

## #114442 — Go Kudo — 2021-05-12T14:39:00+00:00

URL: https://externals.io/message/114378#114442 · In reply to: #114421

I would like to change the proposal to one based on the original proposal
(pecl orng) instead of the confusing RFC proposal.
https://github.com/zeriyoshi/php-ext-orng

But, I am a bit skeptical about bc-break. It is possible to implement it
without destroying the current behavior, but keeping the old implementation
may lead to userland implementations that mess up the state of RNGs in the
future.
I haven't decided whether to include it in the next RFC, but we think we
need to deprecate all functions that use RNGs with global state (shuffle(),
 `array_rand()`, `str_shuffle()`) in the future.

The API in the rejected RFC was confusing because of my attempt to solve
this problem. I've tried to maintain maximum interoperability and usability.

Also, I am happy to see that Nikita's rules for namespace assignment to
extensions have been approved. I'm going to use the `RNG` namespace.

2021年5月12日(水) 4:46 Levi Morrison <levi.morrison@datadoghq.com>:

> 
> > […]
> you
> > […]
>
> I would like to see an extension that doesn't contain the
> backwards-compatibility breaking changes in the RFC. Every function,
> type, and constant should be namespaced according to the extension.
> For instance, if you want to call it `ext/rng`, then the namespace can
> be `rng` or `Rng` or `RNG`.No exceptions for now! The previous
> proposal had namespace things, and un-namespaced things, and breaking
> changes, and I don't think that made a cohesive proposal.
>
> Also, php-src generally doesn't suffix interfaces with the name
> "Interface". Please provide another name for `RNGInterface`, like
> `RandomNumberGenerator` or `RNG`.

---

## #114443 — Go Kudo — 2021-05-12T14:50:23+00:00

URL: https://externals.io/message/114378#114443 · In reply to: #114424

> 1) Get rid of all of the functions.  Object-scoped means... you just have
an object with methods on it.  That's it.
Yes. The previous proposal was a complete mess. We will change it to be
based on the ORNG extension that we originally planned.
https://github.com/zeriyoshi/php-ext-orng

> 2) Don't force people to use a subclass with an incomprehensible name.
In this case, a single class with a constructor parameter that specifies
the algorithm to use is far superior.  Possibly that parameter could be an
object conforming to an interface if you really want, as long as the
default is reasonable so most people never have to use it.
Specifying an algorithm by string is indeed simple and easy to use.
But when the need to generate a fixed sequence arises, such as in test
cases, it becomes difficult to achieve the requirements.
I think the classed algorithm approach can solve this problem, although it
introduces a bit of complexity.

> 3) Perhaps it should be named RandomSequence or similar?  It's not truly
generating random numbers.  It's generating a repeatable but difficult to
produce sequence off of a seed value.  That's not the same thing as
 `random_int()` et al.
I think you're right. However, in the context of other languages, the name
PRNG is used to describe that sequence generator.

> 4) As Levi said, we have a new policy document on namespace usage.  This
is a good first application of it.
Yes. Thank you Nikita :).

2021年5月12日(水) 6:21 Larry Garfield <larry@garfieldtech.com>:

> 
> > […]
>
> I don't work in areas that would tend to need such a thing, but other
> people do so I have no objection to it existing, as long as it's
> well-designed.
>
> > […]
> you
> > […]
>
> Yes.
>
> > […]
>
> 1) Get rid of all of the functions.  Object-scoped means... you just have
> an object with methods on it.  That's it.
>
> 2) Don't force people to use a subclass with an incomprehensible name.  In
> this case, a single class with a constructor parameter that specifies the
> algorithm to use is far superior.  Possibly that parameter could be an
> object conforming to an interface if you really want, as long as the
> default is reasonable so most people never have to use it.
>
> 3) Perhaps it should be named RandomSequence or similar?  It's not truly
> generating random numbers.  It's generating a repeatable but difficult to
> produce sequence off of a seed value.  That's not the same thing as
> `random_int()` et al.
>
> So, at first pass, an API could be as simple as (pseudocode):
>
> class RandomSequence {
>   public function __construct(int $seed = `time()`, $algorithm =
> 'some_default') { ... }
>
>   public function `next()`: int { ... }
> }
>
> And that's it.  That's nice and simple and predictable to use.
>
> 4) As Levi said, we have a new policy document on namespace usage.  This
> is a good first application of it.
>
> --Larry Garfield
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #114444 — Levi Morrison via internals — 2021-05-12T14:51:30+00:00

URL: https://externals.io/message/114378#114444 · In reply to: #114442

> Also, I am happy to see that Nikita's rules for namespace assignment to extensions have been approved. I'm going to use the `RNG` namespace.

Just to be clear, you can only use `RNG` as a namespace if the
extension is named `ext/rng`. You cannot add namespaced things to
`standard` nor `SPL` nor `Core`.

---

## #114445 — Go Kudo — 2021-05-12T14:54:59+00:00

URL: https://externals.io/message/114378#114445 · In reply to: #114444

Sorry about that. I thought I had indicated that I was getting rid of
bc-break and carving out functionality for the `ext/rng` extension in the
context of reverting to an ORNG-like class-based implementation.

2021年5月12日(水) 23:51 Levi Morrison <levi.morrison@datadoghq.com>:

> > […]
> extensions have been approved. I'm going to use the `RNG` namespace.
>
> Just to be clear, you can only use `RNG` as a namespace if the
> extension is named `ext/rng`. You cannot add namespaced things to
> `standard` nor `SPL` nor `Core`.

---

## #114446 — Nikita Popov — 2021-05-12T14:58:37+00:00

URL: https://externals.io/message/114378#114446 · In reply to: #114444

On Wed, May 12, 2021 at 4:51 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> > […]
> extensions have been approved. I'm going to use the `RNG` namespace.
>
> Just to be clear, you can only use `RNG` as a namespace if the
> extension is named `ext/rng`. You cannot add namespaced things to
> `standard` nor `SPL` nor `Core`.
>

This is not correct. The namespace policy RFC specifically and explicitly
allows namespacing of components in standard/core, see
https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl.
Adding something under the RNG\ namespace inside ext/standard is fine
(modulo due diligence on the specific choice of namespace name).

Regards,
Nikita

---

## #114447 — Levi Morrison via internals — 2021-05-12T15:07:20+00:00

URL: https://externals.io/message/114378#114447 · In reply to: #114446

>
> 
> > […]
>
>
> This is not correct. The namespace policy RFC specifically and explicitly allows namespacing of components in standard/core, see https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl. Adding something under the RNG\ namespace inside ext/standard is fine (modulo due diligence on the specific choice of namespace name).
>
> Regards,
> Nikita

It says:

> Because these extensions combine a lot of unrelated or only tangentially related functionality, symbols should not be namespaced under the Core, Standard or Spl namespaces. Instead, these extensions should be considered as a collection of different components, and should be namespaced according to these.

The second sentence is not well defined. I am confident this was
discussed as part of the RFC discussion. The understanding I, and at
least a few others, took away is that it means these extensions can't
namespace anything until another RFC defines that second sentence.

In other words, the RFC says you cannot name things in those
extensions with the namespace "Core", "Standard", nor "SPL", but it
doesn't define what you _can_ use.

This is really important. If the RFC author did not have this same
consensus then this is a MAJOR problem that needs immediate
discussion.

Levi Morrison

---

## #114449 — Christian Schneider — 2021-05-12T15:43:42+00:00

URL: https://externals.io/message/114378#114449 · In reply to: #114424

Am 11.05.2021 um 23:20 schrieb Larry Garfield <larry@garfieldtech.com>:
> 3) Perhaps it should be named RandomSequence or similar?  It's not truly generating random numbers.  It's generating a repeatable but difficult to produce sequence off of a seed value.  That's not the same thing as `random_int()` et al.
> 
> So, at first pass, an API could be as simple as (pseudocode):
> 
> class RandomSequence {
>  public function __construct(int $seed = `time()`, $algorithm = 'some_default') { ... }
> 
>  public function `next()`: int { ... }
> }
> 
> And that's it.  That's nice and simple and predictable to use.


Would the generated values fill the whole int range, i.e. 64 bit on modern systems?

And would it make sense to add max and min for the generated values like we have with `random_int()`?
Because mapping arbitrary int values to a specific range is error-prone: Just using modulo leads to bias in the resulting values.

- Chris

---

## #114453 — drealecs@gmail.com — 2021-05-12T16:34:55+00:00

URL: https://externals.io/message/114378#114453 · In reply to: #114449

On Wed, May 12, 2021 at 6:43 PM Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 11.05.2021 um 23:20 schrieb Larry Garfield <larry@garfieldtech.com>:
> > […]
> generating random numbers.  It's generating a repeatable but difficult to
> produce sequence off of a seed value.  That's not the same thing as
> `random_int()` et al.
> > […]
> 'some_default') { ... }
> > […]
>
>
> Would the generated values fill the whole int range, i.e. 64 bit on modern
> systems?
>
> And would it make sense to add max and min for the generated values like
> we have with `random_int()`?
> Because mapping arbitrary int values to a specific range is error-prone:
> Just using modulo leads to bias in the resulting values.
>
>
What I initially proposed is an interface something like:

interface RandomSource {
    public function next($length): string;
}

where the string returned would be of the specified length and made up of
random bytes.
I understood that internally, an 32/64 bit int is equivalent to 4 or 8
bytes and that various internal implementations already use ints and not
bytes to provide other constructs like `shuffle()` and `array_rand()` with
random behavior.
So I can understand if the function would return an int or an array of
ints. Maybe you can contradict me if I understood this wrong.

But to fulfill all the need for random, one can further use a wrapper class
that can be called RandomGenerator that takes a RandomSource as parameter
and have all types of handy methods:

generateInt($min = 0, $max = PHP_INT_MAX)
generateBoolean()
generateNumber() // float between 0 and 1
generateString($length, $characters = '')


RandomGenerator would take care of the uniform distribution of  values
generated based on uniform distribution of source bytes/ints generated.
I think that keeping a simple way to generate random information is
important so that it can easily be reimplemented in various ways when
needed.
I like the byte approach more because generateString(4, 'abcd') could
consume only 1 byte from the random source.
Of course, in this picture, RandomSource implementations can be
serializable, if it makes sense.

BTW, this name proposal is inspired from this library:
https://github.com/paragonie/RandomLib as I'm not good with namings either.

Alex

---

## #114455 — Rowan Tommins — 2021-05-12T20:27:12+00:00

URL: https://externals.io/message/114378#114455 · In reply to: #114442

> I haven't decided whether to include it in the next RFC, but we think we
> need to deprecate all functions that use RNGs with global state (shuffle(),
> `array_rand()`, `str_shuffle()`) in the future.


I don't understand why that would be necessary or helpful. The majority 
of code using those functions does not need repeatable or configurable 
results, and would not benefit from a more complex API.

If you're just deciding which order to show the user some cute pictures 
of cats, shuffle($array) is much more appropriate than (new 
RNG\Randomiser(RNG\MT15593))->shuffle($array) or whatever the API ends 
up looking like.

I can however see an argument for deprecating srand/mt_srand: if you 
want a reproducible pseudo-random sequence, create an object to manage 
its state; if you don't, leave the engine to manage it for you however 
it wants. The way the seed was initialised would then be entirely an 
implementation detail, just like the algorithm, which already changed in 
7.0.

Regards,

-- 
Rowan Tommins
[IMSoP]