Wow. :)
- Stig
[<[EMAIL PROTECTED]>]
> 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]
--
Stig Sæther Bakken <[EMAIL PROTECTED]>
Fast Search & Transfer ASA, Trondheim, Norway
--
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]
