[PHP-DEV] Re: The rand() can of worms
Bad points: 1) Leaks 2) Inconsistent style 3) Really bizzare macros, etc. Let's put one thing straigt: I merged it already in this early stage (I KNEW it wasn't yet the way it should be, for example the macro thingy: It started out as 2line-macro's, but went bigger. In the optimization and reflection stage, I certainly whould have converted it to a function, but that stage wasn't yet reached) because I thought I would FINALLY ** get comments on the whole thing (AND NOT ABOUT THE PRECISE IMPLEMENTATION, SINCE I STATED VERY CLEARLY THAT WAS NOT YET WHERE YOU NEEDED TO PAY ATTENTION TO). Maybe you don't understand my way of coding (emphasis on CORRECTNESS, the rest comes in later stages). In fact I was REALLY in fast-coding mode because I wanted to commit/merge it before the big part of that introduction I was co-organising. I thought you would be able to discuss it, so after I had time again, I could react to it (in fact, I even doubted wether I got any reactions, since you all didn't seem to care about rand()). I really dislike the way you are handling with this issue: first silently agree, and when nearly FINISHED, go do difficult. In the Netherlads we have a word for this kind of people, but I'm not going to write it down here... --jeroen (still very angry) -- 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]
Re: [PHP-DEV] Re: The rand() can of worms
I really dislike the way you are handling with this issue: first silently agree, I keep seeing this thrown around. 'Silent approval' is an interesting concept. How do you distinguish it from 'silent disapproval'? Are you sure you didn't make an assumption about the way people felt? (We have a saying here in the US about what happens when you assume, but I won't write it down here). Also, as has been pointed out numerous times that there is a huge difference between agreeing with someone's idea (although even this much wasn't clear to me), and agreeing to a given implementation. George -- 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-DEV] Re: The rand() can of worms
I *NEVER* have anything to say until I have seen the code. Otherwise, it's just a bunch of castles in the air. Okay, that's a point. That is not the custom where I learnwork, actually, there is a saying that design planning is 67% of the job, implementing just 33%. That is if you want a good stable code. (I know, that seems to contradict, but just read on). But, I got no comments at all (except the first time one by Rasmus) on the design. The fact wether something compiles, and how quick it is, is simply irrelevant until the final stage, but people don't seem to agree with me on that point. Compile run is a typical Microsoft approach to programming. In the ideal situation a program won't compile until it is finished, and I'm fine with that. Everybody seems to fall about compile issues and performance problems and leaks. Except for performance problems, which are often related to design, this should have been irrelevant for the discussion (well, not about wether it should already have been merged, but about wether this is the way to go.) And about design, I haven't been given opportunity to discuss about it. I made the mistake to merge it, I shouldn't have done that. But to me it *seemed* the only way to start a discussion. I was really hungry for feedback, which wasn't coming. Apperently because a lot of people go for that compilerun, and discuss afterwards strategy, which is at my place considered the sub-university way of programming. patch that is in such a sorry state by mergeing it to HEAD. Let me know when it is *STABLE*, when it will compile on my machine, and run with a That is the point I make here, I wanted to discuss about the strategy and design. You did have quite some comments on it, and I am of course listening to them. But I didn't get the chance to act according to your remarks/suggestings, rather, it is reverted. Of course, I know now that you really want to have a stable HEAD. But I asked a lot of times to give me feedback on that and other issues, and Zeev even suggested to commit my initial work straight to HEAD. But please you should have let me know that that is an issue with most of you, I only had Zeev's mails as reference, and apperently a lot of people have different feeling about it (or I really misunderstood him of course). --Jeroen PS: it's too much to read all now, so it'll take another day (or two?) before I can get to reply to other mails. -- 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]
Re: [PHP-DEV] Re: The rand() can of worms
Maybe you don't understand my way of coding (emphasis on CORRECTNESS, the rest comes in later stages). In fact I was REALLY in fast-coding mode because I wanted to commit/merge it before the big part of that introduction I was co-organising. I thought you would be able to discuss it, so after I had time again, I could react to it (in fact, I even doubted wether I got any reactions, since you all didn't seem to care about rand()). Jeroen, I wish you wouldn't take things so personally. You do have to understand that this is a large cooperative project. Committing something that prevents the HEAD branch from building and then disappearing is about the biggest sin you can commit. Yes, it forces *everyone* to notice what you are doing and it sounds like that this was partly the effect you were trying to get. But many of these people are working on their own bits and pieces and by breaking the build you are interrupting everyone from working on their own code. It is not surprising that the reaction was less than positive. If you commit something that breaks the build, which happens, I have done it many times, make sure you will have the time to fix things quickly or if you don't, hold off on committing things that you know might break the build. I have a rather large commit sitting here on my laptop which I would love some comments on, but it is extremely likely to break all sorts of things. I will be adding a temporary configure switch which turns my code on and off and making sure that without the switch nothing changes before I commit this beast. The configure switch may actually be permanent. Need to do a few benchmarks to determine that... -Rasmus -- 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]
