std.getopt suggestion

[Andrei Alexandrescu]

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