On 12 June 2012 22:08, Tom Gundersen <teg@jklm.no> wrote:
Hi Igor,
Hi Tom, thanks for your reply.
Answering off-list, as I think this discussion has exceeded its usefulness for most people.
Sure, I didn't expect such unwelcome and rather hostile reaction. Neither did I expect borrowing the idea from my isYes branch in such, well, *weird* way as well. But I'd prefer answering to the list back. […]
1) doesn't apply to master
What a tragedy. Are you git newcomer, aren't you?
This is a trivial patch, and as such I would appreciate not having to resolve conflicts (I'm happy to do that if you have a big complex branch for me to merge where rebasing it might not be the best idea).
Look, it was just a draft branch. That's why it had both /bin/sh and bash' versions.
2) adds dead code
"Dead code" doesn't bite, don't be afraid, boy.
We don't add dead code.
I don't urge anyone to do that. My answer to the 1st item above has explained why it was there. It could be eliminated on every following stage easily.
3) uses camelCase where we use lower_case everywhere else
Yeah, I remember yours strict consistency comparing either "yYeEsS" or "YyEeSs" ;-P
Please follow the current coding style. It contains inconsistencies, but we want to reduce them.
It surely does. It has as [[ ]] && {} and if [[ ]]; then. I just don't see any guidelines available to follow — are there any?
4) fails to quote properly
Another tragedy. Feel free to submit patches, dude.
Just to clarify how we work: we don't accept patches with known deficiencies, but rather point them out and wait for a fixed patch to be resubmitted. I believe this is how most open-source projects work.
It would be nice and pretty w/o such hostile reaction from Dave.
Show me your code which doesn't suck, then ask my respect.
I'd suggest using "git blame" or "git log". Or even checking out mkinitcpio or pacman. Dave knows what he is doing, I suggest listening to him.
You mean "going away"? :)
As to the patch itself: avoiding duplication of code is generally a good thing. Though in this case the code is SO trivial that the benefit is minimal. Also, it would mean that people would have to look up the function to check if there are any "gotchas" in it, rather than just reading it off inline. These things have to be weighted against each other. Finally, there is the consideration that whenever we add a patch, no matter how trivial, there is a chance that a bug is introduced, so we are biased against not adding patches unless the benefit is clear.
It's quite clear benefits. Getting rid of tedious each-time and each-place comparing is benefit. And looking up a function is what programmers should be get used to as walking on theirs foots. It's kinda nonsense to excuse avoiding subroutine use by that reason.
As to your rather condescending email about subroutines, thanks for that, but I am well aware of the basics of the theory of programming languages (it being my day-job).
-t
Okay. -- End of message. Next message?