Re: About the Rand Merge: apologoy & how further?

Wow. :) - Stig [<jeroen@php.net>] > Hi All, > > I've finally finished reading what has been written about the > rand-merge, and have come to a few conclusions. I'll keep it short. > > First, I really shouldn't have merged rand without asking. First of > all, it is indeed against CVS-RULES. Most importantly, I disturbed > people working on extensions by introducing leaks in the basic code, > which is (naturally) bad. I simply shouldhave asked: please review > RAND_REDESIGN. The problem though is that I did, and nobody > complained... (a few days before the merge). > > I want to offer my apologies to anyone who was disturbed by it. I > shouldn't have done it, and asked for comments on the branch first. I > didn't realize that people were waiting for it, since I hardly got any > feedback in this issue, while after all it seems people _are_ concerned > with it. > > Secondly, I should really adjust my attitude when 'defending' from > your remarks. At first I didn't realize the pointe in your objections > (the code itself), and simply didn't understand why there were > objection just after I already did so much work on it, and not > earlier. Please note that I certainly did not think I was ready, but I > did (wrongfully) think the code was good enough (didn't yet optimize & > I didn't yet clean up code&macro's, but I thought it did work > according to my second proposal). This does not however warrant how I > reacted, so I truly want to apologize for it. > > > How further now? I see several problems which need to be sorted > out. Before discussion the code, you need to determine what the code > should do. This (I'm speaking in general now) is the most important > step in creating/modifying code, and therefore I had put a lot of > effort to get feedback on the subject - in vain. > > [Step 1: discussion behaviour of code] I will give it a retry now. As > said before, please see > > http://marc.theaimsgroup.com/?l=php-dev&m=99695846612079&w=2 > for the > original proposal and discussion afterwards, and > > http://marc.theaimsgroup.com/?l=php-dev&m=99802330332087&w=2 > for my > second proposal. Based on Jani's recent suggestion to use other > function names, and on a couple of extra ideas from myself, this is > the third version of the proposal: > > --- <Rand-change proposal version 3> --- > > * float random() - gives a random number in the range [0,1) * int > random(int min, int max) - gives a random number within the range, > range can be anything withing LONG_MIN to LONG_MAX. * void > set_random() - reset random number generator to ini-default, and make > sure there is a random seed if applicable * void set_random(string > algorithm[, int seed]) - set random generator with specific seed, in > order to get a reproducable sequence of random numbers * the old > functions: [mt_][s]rand and [mt _]getrandmax - these are deprecated, > but remain intact until next really-hard-compatibility-breaking > version of PHP. * All other random-functions use random() in their > internal calls, so they can be made predictable the same way as > random() > > What this will accomplish: - Simplify random numbers: people usually > just want random numbers - All functions will - by default - start > using mt now, so no need for mt_array_rand - Introduce an explicit way > to get a reproducable sequence, which will be portable too - Introduce > possibility to easily add random number source, without polluting > php-namespace with another set of rand/srand/getrandmax/shuffle and > array_rand functions. Also introducing proper syntax possibility for > real-random-number sources, such as lavalamps ;), or radio-sources. - > Make random thread-safe, which was only the case for mt up until now > > BC: The are only possible BC-problems when you rely on the > undocumented feature of getting a reproducable sequence of 'random' > numbers. Getting predicable random numbers is now supported, it > wasn't supported in the past (well, you could make it to, but it > wasn't portable, documented, nor thread safe). Array-shuffle and > alike weren't predictable, a change in algorithm whould have changed > behaviour too, and an extension using system rand() would also have > nuked your code. > > --- </Rand-change proposal version 3> --- > > Comments of any kind are very welcome, if you simply want to express > your agreeance or disagreeance, go to > http://www.a-eskwadraat.nl/~jeroen/rand > > [Step 2: Choice on general design issues] What strategy is followed to > implement this? Please let's suspend this discussion until Step 1 is > finished, because this depends greatly on step 1. Discussion PHPAPI > functions should also be held in this stage. > > [Step 3: Implementation] Details and creation of the code. Details > about, for example, use of macro's, should belong here. Let's suspend > this discussion also until the former 2 steps are finished. > > [Step 4: testing and merging] Testing will be possible this time > before the merge ;-) > > > If you simply want to give your vote, go to > http://www.a-eskwadraat.nl/~jeroen/rand You can vote there, > visible > for everybody, without polluting the php-dev ML. I really appreciate > it if people who have an opinion on this, give their vote. There's > also room for extra comments. > > Thanks in advance, > > Jeroen van Wolffelaar > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net -- Stig Sæther Bakken <ssb@alltheweb.com> Fast Search & Transfer ASA, Trondheim, Norway