std.getopt suggestion

[Dmitry Olshansky]

On 29.09.2011 21:01, Andrei Alexandrescu wrote:
> 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.
>

IMHO it's about the best suggestion we can get from this thread.
Just make 'option' objects analogous to existing config values: 
getopt(...< use '=' >..., assignChar(':'), ...< use ':' >...);

Both parties are happy: a helper struct is here, and getopt is still not 
a member ;)


-- 
Dmitry Olshansky