std.getopt suggestion

[Christophe]

Jens Mueller , dans le message (digitalmars.D:146111), a écrit :
> Christophe wrote:
>> Andrei Alexandrescu , dans le message (digitalmars.D:146070), a écrit :
>> > On 10/4/11 2:39 PM, Andrei Alexandrescu wrote:
>> >> On 10/4/11 12:05 PM, Christophe wrote:
>> >>> Andrej Mitrovic , dans le message (digitalmars.D:146060), a écrit :
>> >>>> I'm don't often use getopt just for the fact that I can't use
>> >>>> single-dash arguments like '-release'. DMD uses this syntax, and so to
>> >>>> other tools. It's not a big deal thanks to D's fantastic
>> >>>> string-manipulation abilities, so I just roll my own. All I need is a
>> >>>> switch(args) statement.
>> >>>
>> >>> I don't use getopt often either. That does not prevent me to wish getopt
>> >>> could become adequate to my needs...
>> >>
>> >> It already is because your needs are the empty set.
>> >>
>> >> Andrei
>> > 
>> > On second thought what you said suggests your needs set may be nonempty, 
>> > but said needs are not fulfilled by the current std.getopt.
>> > 
>> > What exactly in std.getopt does not fulfill your needs? Would assembling 
>> > the three variables into a structure help?
>> 
>> 
>> No, it wouldn't.
>> 
>> The main reason why I don't want to use getopt is because the syntax "-o 
>> output" (short-option, space, argument), and that is the main thing 
>> I want to do. I think I posted about this in the thread.
> 
> This will be supported with my changes. I hope I can act soon on the
> feedback and clean up the pull request.
> 
>> Enabling single-dash long option would be nice too.
> 
> I suppose there is no technical to not support this kind of option.
> Though it does make configuring getopt more difficult and I don't see
> enough usage to add it. Why is this important to you? I see little
> benefit of -pedantic over --pedantic. If you believe this option is very
> important (because you want to save a single character), then you could
> provide the short alias -p.
> Is this just a matter of taste?
> Please convince me.

I can't convince you on that, because I am not really convinced myself.
--longOption is the posix way, so it is fine with me, even if I think 
-longOption could be nicer to some eyes.

However, the current way to parametrise getopt is to change the 
character for options ('-'), and I belive the string for long option is 
twice the character for short option ("--"). I don't think this makes 
great sense. We could parametrize a long option string (that we could 
set to "-"), and a short option char (that may or may not be 
automatically set to longOptionString[0]). But no parametrization on the 
shortOptionChar and on the longOptionString is fine too. Nobody would 
complain the call to getopt could be screwed up by another programmer 
modifiying the shortOptionChar behind your back if this could not be 
changed in the first place...

Well, too much parametrization is wrong. But the posix way has to be 
supported, and it includes "-o output" (which is much more helpful than 
-ooutput for readability and for auto-completion in the shell).

-- 
Christophe