std.getopt suggestion
Christophe
travert at phare.normalesup.org
Thu Sep 29 09:53:24 PDT 2011
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).
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.
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, ':', ...)
--
Christophe
More information about the Digitalmars-d
mailing list