On 9/29/11 11:54 AM, Jonathan M Davis wrote:
On Thursday, September 29, 2011 11:39 Andrei Alexandrescu wrote:
I don't think it would improve the module design, even without
considering cost of change. It just adds useless clutter.
Well, out of those who have responded in this thread, you're the only one who
thinks that. Everyone else has been in favor of either making those config
options passable to getopt or in favor of putting getopt on a struct which
holds the those config options (with a free function which uses the init value
of the struct for the common case).
Upon further thinking, I'm even less sure than before that that's a good
idea.
And yes, that's an argument by ad populum
(or whatever the exact name is), but what's considered "clutter" is
subjective.
Clutter is stuff on top of the baseline that doesn't pull its weight.
The baseline is:
"In order to get a command-line options for your program, you must
import std.getopt, define the variables holding the options, and call a
function to fill them."
Yes, the improvement would be relatively minor, but so's the cost
of the change, and while it doesn't necessarily show that you're wrong when no
one seems to agree with you, it does at least say something when no one agrees
with you.
A good argument would be a whole lot better. My perception is, again,
that we're not looking at a small improvement. It's a step back.
Andrei
