Am 15.10.2023 um 19:24 schrieb Tim Düsterhus <t...@bastelstu.be>: > Making getFloat(float $min = 0.0, float $max = 1.0, IntervalBoundary > $boundary = IntervalBoundary::ClosedOpen) would seemingly make it legal to > call ->getFloat(0.5), which I consider to be worse than nextFloat().
While I understand that you find getFloat(0.5) undesirable I would not consider it illegal, e.g. getFloat(max:5). Additionally I would consider getInt(max:100) to be a very valid usage too. > Side note: The implementation of nextFloat() is much more efficient than that > of getFloat(0.0, 1.0) and the output will differ even for the same seeded > engine. The domain of legal return values is identical. This sounds like an implementation detail as I'm pretty sure you could switch to that fast path easily enough if neither of the arguments were given. Side-note: The case of nextInt() is a bit trickier and strikes me as a bit of a weird API and I'd consider dropping it too: Having the max value depend on the Randomizer engine makes the generated values unstable in regards to switch the Engine. And if I read the documentation correctly then it only generates 32 bit values (or should it be 31 bits as it returns positive values only?). I think it would be clearer to require the Engine to provide at least 4 bytes and then specify the default max value of getInt() to be 2^31, optionally overridable with something up to PHP_INT_MAX. So in summary I'd support both adding default values to getInt()/getFloat() as well as dropping nextFloat() in favor of getFloat() (and possible nextInt() with getInt()). Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
