Ok, We're now in a situation that has to be resolved.  I think there are 3 

- The way php-dev behaved was flawed.  While there's truth in what Sterling 
said about opensource projects, I have to say that the amount Jeroen put 
into the RFC about the subject is not very common.  Thus, I can understand 
his anger, when php-dev suddenly wakes up after he's done all the work.

- After looking at the code, I have to agree with Sterling about the 
style.  Big chunked macros which should be functions, over-all breakage, 
etc., for something that is, after all, just supposed to return 
integers.  It looks a bit like killing a fly with a cannon.

- We can't ignore the fact that a much simpler and even less BC breaking 
way was offered - simply creating a new function named random(), 
unfortunately, after the work that's been done.

In my opinion, if we combine these three into actions, then:
- We owe an apology to Jeroen
- We should revert the code and implement the KISS approach by simply 
introducing a new function.


At 02:34 03-09-01, Sterling Hughes wrote:
>     Howdy,
>     I have a few problems with the latest random number related commits,
>     most importantly being the quality of the underlying code, rather
>     than some of the changes it implements (which are also un-necessary,
>     imho, if it ain't broke -- don't "fix" it).
>     1) On a style note, the code makes poor use of macro's,
>     pim_srand_common is a good example of a macro gone wrong..
>     2) It's un-optimized, and the code does not follow a logical
>     structure, one indication of this is the PHP_FUNCTION_RAND() and
>     PHP_RAND_RANGE(), which does too much for a macro in this case (and
>     comments like that really don't belong in a macro).  Also, folks,
>     don't use "register" on a variable that will be accessed twice.
>     3) I don't think the extra level of abstraction is warranted in
>     this case -- it slows things down, it doesn't speed them up, and
>     there is really no great improvement from an API perspective to
>     doing this.
>     4) What was sooooooo wrong about the way we were doing things?
>     Even though we don't have a voting system, I'm a strong -1 on this
>     patch. :)))
>     Instead -- changes that I think would be a good idea (and I'll
>     implement these if you don't want to Jeroen) are:
>     a) Making the seed argument optional to [mt_]srand(), and use the most
>     random seed possible if no seed is specified, this is a good way to
>     help out people.
>     b) Update to the php4 api, and remove some of the redundant logic in 
> rand.c
>     pre-patch (well redundant from a PHP4 perspective).
>     -Sterling
>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]

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]

Reply via email to