Re: [PHP-DEV] [VOTE] Object scoped RNG implementation
On Fri, Apr 2, 2021, at 4:56 PM, Kamil Tekiela wrote: > Hi Go Kudo, > > First, let me say that I believe we need such implementation in PHP and I > would like to see object scoped RNG as part of the standard. However, I > have voted no for a number of reasons. Let me list them from the > perspective of a noob PHP user. > > - I really do not understand why we are introducing new functions. Can't > the classes implement the necessary methods to get integers, doubles, and > string of bytes? As a new user I would be completely overwhelmed by all > these functions: rand(), mt_rand(), rng_int(), rng_next(), rng_next64(). > Which one should I use? What is the difference between rng_next() > and rng_next64? > - As soon as I left the RFC page I forgot what the new classes were called. > I still can't tell from memory what's their name. I understand what they > mean, but they are definitely not friendly names. > - What's the difference between MT19937 and XorShift128Plus? They are > different algorithms but which one should I pick? I tested the > implementation locally and I see no difference in performance. > - I am not a fan of adding a new optional parameter to shuffle() and > friends. I'd prefer to have a method in the class that I can pass an array > to. > - What is the default seed? Do I have to provide a seed each time? Why > can't the seed be done automatically? > - Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers. > What's the real-life purpose of this flag? > - I don't see any use in supporting userland implementations. Why can't > they create separate libraries? I don't know about performance, but if > someone wants to have custom RNG then I don't think they worry about > performance. > - When using the functions the performance was 50% worse than when calling > ->next() directly. Is this right or is the implementation going to be > optimized further? The fastest way to get a random number seems to be > mt_rand() based on my tests. > > I would rather like to see a single class called RNG/Random that implements > RNG/RandomInterface. The constructor of the class would take 2 arguments. > The first is the algorithm with a default either MT or XORShift. The second > is an optional seed. If no seed is provided then the seed is generated > automatically like in mt_srand(). The class would then implement methods > like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(), > stringShuffle(), randomArrayKeys(). I would keep the standard functions as > they are. Let them use MT by default. We could even deprecate them in > future if this takes off. > > This would make it painfully obvious what the class does and how to use it. > No more procedural code. I would also make the class final so that you > can't inherit from it, but that is highly opinion-based. > Now that I have written this, I read previous conversations and it looks to > me like what I would like is what you had previously. > > I'm sorry if I complain too much, but I would like to see something like > this implemented, just not like you are proposing right now. It is too > messy for me and I know I wouldn't like it if I had to use it. > > Regards, > Kamil I also didn't pay close attention to the previous discussion, but reading the RFC I agree with all of this. The functionality proposed is good and needed, but the API is a mess. What Kamil suggests is far better, and fully commits to being OOPy. Given that the use case is for situations where you need a predictable and repeatable random sequence, such as Fibers or threads or such, going all-in on an object seems like the correct approach. One thing I'm not 100% clear on from the RFC, does this also deprecate random_int()/random_bytes()? Those are (AFAIK) unseeded, so they seem like they'd continue to serve their current purpose, but it's not clear from the RFC. Voting no for now, but I would welcome a resubmission with a cleaner API, even in this cycle. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Object scoped RNG implementation
On Fri, Apr 2, 2021, 23:56 Kamil Tekiela wrote: > Hi Go Kudo, > > First, let me say that I believe we need such implementation in PHP and I > would like to see object scoped RNG as part of the standard. However, I > have voted no for a number of reasons. Let me list them from the > perspective of a noob PHP user. > > - I really do not understand why we are introducing new functions. Can't > the classes implement the necessary methods to get integers, doubles, and > string of bytes? As a new user I would be completely overwhelmed by all > these functions: rand(), mt_rand(), rng_int(), rng_next(), rng_next64(). > Which one should I use? What is the difference between rng_next() > and rng_next64? > - As soon as I left the RFC page I forgot what the new classes were called. > I still can't tell from memory what's their name. I understand what they > mean, but they are definitely not friendly names. > - What's the difference between MT19937 and XorShift128Plus? They are > different algorithms but which one should I pick? I tested the > implementation locally and I see no difference in performance. > - I am not a fan of adding a new optional parameter to shuffle() and > friends. I'd prefer to have a method in the class that I can pass an array > to. > - What is the default seed? Do I have to provide a seed each time? Why > can't the seed be done automatically? > - Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers. > What's the real-life purpose of this flag? > - I don't see any use in supporting userland implementations. Why can't > they create separate libraries? I don't know about performance, but if > someone wants to have custom RNG then I don't think they worry about > performance. > - When using the functions the performance was 50% worse than when calling > ->next() directly. Is this right or is the implementation going to be > optimized further? The fastest way to get a random number seems to be > mt_rand() based on my tests. > > I would rather like to see a single class called RNG/Random that implements > RNG/RandomInterface. The constructor of the class would take 2 arguments. > The first is the algorithm with a default either MT or XORShift. The second > is an optional seed. If no seed is provided then the seed is generated > automatically like in mt_srand(). The class would then implement methods > like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(), > stringShuffle(), randomArrayKeys(). I would keep the standard functions as > they are. Let them use MT by default. We could even deprecate them in > future if this takes off. > > This would make it painfully obvious what the class does and how to use it. > No more procedural code. I would also make the class final so that you > can't inherit from it, but that is highly opinion-based. > Now that I have written this, I read previous conversations and it looks to > me like what I would like is what you had previously. > > I'm sorry if I complain too much, but I would like to see something like > this implemented, just not like you are proposing right now. It is too > messy for me and I know I wouldn't like it if I had to use it. > Changed my vote to "no" after this in-detail review. Overall, I was conflicted, and voted "yes" especially because we do really need a better and reproducible seeding solution for RNG, and the current API is insufficient. The API proposed so far is quite terrible though, and if the vote passed, we'd have to stick with it for an infinity of years. >
Re: [PHP-DEV] [VOTE] Object scoped RNG implementation
Hi Go Kudo, First, let me say that I believe we need such implementation in PHP and I would like to see object scoped RNG as part of the standard. However, I have voted no for a number of reasons. Let me list them from the perspective of a noob PHP user. - I really do not understand why we are introducing new functions. Can't the classes implement the necessary methods to get integers, doubles, and string of bytes? As a new user I would be completely overwhelmed by all these functions: rand(), mt_rand(), rng_int(), rng_next(), rng_next64(). Which one should I use? What is the difference between rng_next() and rng_next64? - As soon as I left the RFC page I forgot what the new classes were called. I still can't tell from memory what's their name. I understand what they mean, but they are definitely not friendly names. - What's the difference between MT19937 and XorShift128Plus? They are different algorithms but which one should I pick? I tested the implementation locally and I see no difference in performance. - I am not a fan of adding a new optional parameter to shuffle() and friends. I'd prefer to have a method in the class that I can pass an array to. - What is the default seed? Do I have to provide a seed each time? Why can't the seed be done automatically? - Signed? Unsigned? As far as I know, PHP doesn't have unsigned integers. What's the real-life purpose of this flag? - I don't see any use in supporting userland implementations. Why can't they create separate libraries? I don't know about performance, but if someone wants to have custom RNG then I don't think they worry about performance. - When using the functions the performance was 50% worse than when calling ->next() directly. Is this right or is the implementation going to be optimized further? The fastest way to get a random number seems to be mt_rand() based on my tests. I would rather like to see a single class called RNG/Random that implements RNG/RandomInterface. The constructor of the class would take 2 arguments. The first is the algorithm with a default either MT or XORShift. The second is an optional seed. If no seed is provided then the seed is generated automatically like in mt_srand(). The class would then implement methods like: nextInt(), nextDouble(), nextBytes(), arrayShuffle(), stringShuffle(), randomArrayKeys(). I would keep the standard functions as they are. Let them use MT by default. We could even deprecate them in future if this takes off. This would make it painfully obvious what the class does and how to use it. No more procedural code. I would also make the class final so that you can't inherit from it, but that is highly opinion-based. Now that I have written this, I read previous conversations and it looks to me like what I would like is what you had previously. I'm sorry if I complain too much, but I would like to see something like this implemented, just not like you are proposing right now. It is too messy for me and I know I wouldn't like it if I had to use it. Regards, Kamil
Re: [PHP-DEV] [VOTE] noreturn type
I am still not comfortable with the error message "Nothing was expected to be returned" which is very confusing and I would change it to "was expected to throw or exit" or "was expected to never return". I went with "never" because it just reads better: "Function abc returns never" instead of "Function abc returns noreturn". If "never" wins then the other error message "A noreturn function must not return" must also be changed. Maybe "The function must never return"
[PHP-DEV] What is the equivalent of zend_object_store_get_object in PHP7/8
Internals, In the wiki( https://wiki.php.net/internals/engine/objects), there is an occurrence of "zend_object_store_get_object()". I looked in the github repository but I can't find its implementation. Do you have any information on this function ? - zend_object_store_get_object() - zend_objects_store_add_ref() Regards, Serge
