On 9/29/11 9:53 AM, Christophe wrote:
Andrei Alexandrescu , dans le message (digitalmars.D:145742), a écrit :
4. If you need to run getopt multiple times - particularly if you need to run
it with different configurations each time - it's definitely cleaner to do that
when you can just use a different GetOpt instance in each case. You don't have
to worry about one run of getopt affecting another. Now, this matters far less
for getopt than it would your average function, since it would be highly
abnormal to need to run getopt multiple times like that, but the general
design principle holds.
It would be quite abnormal to run getopt multiple times in the same app
with different configurations. So in this case using globals is
_better_, not worse.
I think it is a bad to restrict the use of such a nice function to only
one call per program because you want to make this precise call a bit
simpler (and it is not simpler if you have to clean up the options after
the call in case somebody else is going to use it).
I wrote: "It would be quite abnormal to run getopt multiple times in the
same app with different configurations." Let me rephrase a bit: "Running
getopt multiple times in the same app with different configurations
would be quite abnormal."
Using globals seems to be easier to you because it is what you are used
to because of the previous langage your learned, but I do not buy that
it is a proper D-way of doing things.
Well I need go get with the times.
You already did a whole work to pass so many options as arguments, I'm
still asking myself why you left 3 options behind. Implementation issues?
BTW, I don't like to use a OptGeter.getopt(...), I prefer to pass all
options as arguments to getopt. Either something like getopt(...,
OptGetter, ...) or getopt(..., option.equalsign, ':', ...)
That fits better within the current design.
Andrei
