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¯o'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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
