Hello Nikita.
> In addition to the functions you already list, I'd add
>function rng_bytes(RNGInterface $rng, int $length): string;
>function rng_between(RNGInterface $rng, int $min, int $max): int;
Certainly these are useful. I've added this to the RFC in TypeC.
> Just to share another p
On Tue, Jan 5, 2021 at 6:40 PM Go Kudo wrote:
> Thanks Nikita.
>
> Thanks for the input. This looks like a very smart solution.
> I've edited the RFC and added a new proposal as TypeC.
>
> https://wiki.php.net/rfc/object_scope_prng
>
In addition to the functions you already list, I'd add
fu
Thanks Nikita.
Thanks for the input. This looks like a very smart solution.
I've edited the RFC and added a new proposal as TypeC.
https://wiki.php.net/rfc/object_scope_prng
However, I have a couple of concerns. The first is that users will have to
be careful with RNG instances (for better or wo
On Thu, Dec 24, 2020 at 5:12 PM zeriyoshi wrote:
> I updated the RFC draft and changed it to a proposal to bifurcate the
> interface.
>
> https://wiki.php.net/rfc/object_scope_prng
>
> At the same time, I was looking into the RNG problem in Swoole and found
> out that the problem was actually occ
On 01.01.21 20:22, Go Kudo wrote:
> Hi Marc, and sorry for the late reply. Email has been marked as spam...
>
>> I would expect the Random number generator to implement from Iterator
> using an integer for current() value
>> and providing utility functions (simple functions or methods of another
Hi Marc, and sorry for the late reply. Email has been marked as spam...
> I would expect the Random number generator to implement from Iterator
using an integer for current() value
> and providing utility functions (simple functions or methods of another
class) for shuffle, random array entry like
Hi zeriyoshi,
On 23.12.20 14:41, zeriyoshi wrote:
> Thanks tyson.
>
>> This would also make it easier to use those generators in brand new
> algorithms that weren't in the initial RFC.
>> (or in algorithms written by users in PHP)
> This suggestion seems to make sense. Maybe the RNG should only fo
Thanks tyson.
> This would also make it easier to use those generators in brand new
algorithms that weren't in the initial RFC.
> (or in algorithms written by users in PHP)
This suggestion seems to make sense. Maybe the RNG should only focus on
generating random numbers and not anything else.
How
Hi Go Kudo,
**A possible alternative that is widely used in other programming languages is
to limit the interface API to only generating bytes/integers,**
and to provide global functions that would use generic random number generator
objects (from internal or user-provided code) in their algorit
Thanks. I have edited the RFC based on your question.
> Method names: you don't need to emulate the conventions from non-OOP
code, e.g. string_shuffle() --> strShuffle and array_rand() -->
arrayRand(). Use a more naturally readable convention like shuffleString().
As mentioned in the RFC, it is i
On Sun, Dec 20, 2020 at 6:45 AM zeriyoshi wrote:
> Thanks cmb. I have created a first draft of an RFC. I think I've covered
> all the necessary requirements, but I'd like to know if there are any
> problems.
> https://wiki.php.net/rfc/object_scope_prng
A few IMHO comments:
* Namespaces are cont
11 matches
Mail list logo
