Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118817
Message-ID: <196dba6f-7800-134b-fbaa-9e1cbcf5bd85@wcflabs.de>
Date: Sat, 15 Oct 2022 11:19:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.3.2
Content-Language: de-DE
To: =?UTF-8?Q?Alexandru_P=c4=83tr=c4=83nescu?= <drealecs@gmail.com>
Cc: PHP internals <internals@lists.php.net>, tim@bastelstu.be
References: <5ceebae4-a3fb-5d29-cdb7-dceed7b07c78@wcflabs.de>
 <CAAwdEzCVokPfcavL6ygrQqXmfBEcaSG-tYOnkXhTMJmj7j8q1g@mail.gmail.com>
Reply-To: =?UTF-8?Q?Joshua_R=c3=bcsweg?= <josh@wcflabs.de>
In-Reply-To: <CAAwdEzCVokPfcavL6ygrQqXmfBEcaSG-tYOnkXhTMJmj7j8q1g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC [Discussion]: Randomizer Additions
From: internals@lists.php.net ("Joshua Rüsweg via internals")

Hi

> For completeness, it would be good to have nextBool() as well.

I'm just wondering if that's really necessary. Generating a boolean is 
trivial with the nextFloat method (see example 1. Simulate a coinflip 
from the RFC).

> No, IMO. Mathematically it doesn't really make sense and talking about 
> floats, it will also be a very corner case not reached in tests that 
> might happen in production rarely and break things.

Why does it not make mathematical sense? With the nextFloat method, I 
can understand the argument, because that is otherwise opaque, 
especially when you work with probabilities. With the getFloat method, 
however, I can imagine a few cases in which this makes sense. In our 
example, for example, we calculate a random longitude and latitude with 
the method. However, the value of Lat: +90.0 Lng: +180.0 cannot be 
generated, although it is a valid value. However, the value of Lat: 
-90.0 Lng: -180.0 is included. Am I missing something, or is there 
currently no simple mathematical way to implement this with an 
open-right interval?


> I am having another small issue.
> As the Randomizer class is final, I guess this will not be perfectly 
> polyfillable in userland.
> So... , if accepted, would it be completely wrong to have these new 
> methods in PHP 8.2? What can it break?

I am relatively new and have little to no experience with contributing 
PHP functions, but I don't think this should be done. There is a good 
reason why this is not done and it only causes confusion if any 
functions are introduced after the feature freeze. In the end, however, 
I think it is the release manager who decides.


Cheers

Joshua Rüsweg