Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118828
MIME-Version: 1.0
References: <5ceebae4-a3fb-5d29-cdb7-dceed7b07c78@wcflabs.de>
In-Reply-To: <5ceebae4-a3fb-5d29-cdb7-dceed7b07c78@wcflabs.de>
Date: Sun, 16 Oct 2022 22:24:38 +0200
Message-ID: <CA+kxMuQECpLyt_D63jzBB1T4K57eVCCHD7JToA==bbHojkhb9w@mail.gmail.com>
To: =?UTF-8?Q?Joshua_R=C3=BCsweg?= <josh@wcflabs.de>
Cc: internals@lists.php.net, tim@bastelstu.be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC [Discussion]: Randomizer Additions
From: Danack@basereality.com (Dan Ackroyd)

Hello Joshua,

> Shall an option be added to getFloat() that changes the logic to
select from [$min, $max] (i.e. allowing the maximum to be returned)? And
how should that look like? Boolean parameter? Enum?

An enum would probably be nice, and possibly be for all four cases of
min_(inclusive|exclusive)_max_(inclusive|exclusive) unless there is a
technical reason to not include all of them.

> Generating a random string containing specific characters...thus requires=
 multiple lines of code for what effectively is a very simple operation.

Yeah, though those lines of code add distinction and emphasis for is
meant by character.

In particular, users might be surprised when they give this string
"abc=F0=9F=98=8B=F0=9F=91=A8=E2=80=8D=F0=9F=91=A9=E2=80=8D=F0=9F=91=A6"* an=
d get a non-ascii result.

You're going to need to be really precise on the naming and I'm not at
all sure there is a single version that would be useful enough to
belong in core.

> whereas a 64 Bit engine could generate randomness for 8 characters at onc=
e.

I'm really not sure that many programs are going to be speed limited
by random number generation.

For those that are, writing their own generator to consume all 64 bits
of randomness for each call sounds reasonably sensible, unless a
useful general api can be thought of.

For the float side of the RFC, as there are technical limitations on
which platforms it would be usable on, there needs to be a way of
determining whether the nextFloat and getFloat methods are going to
work. The way this is done on Imagick is to put appropriate defines in
the stub file and in the C code implementations so that the methods
aren't available on the class for the platforms where it isn't going
to function correctly.

I made a PR for that to Tim's repo, though I don't know of an
environment where it can be tested.

cheers
Dan
Ack

* For those who get a mangled version, the "characters" there are 'a'
'b' 'c' 'smily-face' 'man +  zerowidth joiner + woman + zerowidth
joiner + child'. The last is a character that takes a mere 18 bytes to
represent.