About the Rand Merge: apologoy & how further?

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