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