On 5/28/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 28.05.2005 um 13:36 schrieb Stephen Deasey:
>
> > To be compatible, the type specifier would have to be the third arg,
> > but then you couldn't specify the type without also specifying a
> > default. I don't see a clean way to do it...
>
>
> Hm.. so you are after
>
> arg {arg val} args
>
> type of compatibility as in Tcl proc? I did not think about that
> because we are using our own parser. What is the benefit/reason
> to maintain this kind of compatibility when we already preprocess
> args ourselves?
It will confuse people who read the code, don't you think?
Some Unix utilities use + to signify flipping an option when ther are
many, so you could end up with something like this:
ns_parseargs {+bool -opt {-opt def} arg {arg def} args}
This disadvantage of this is that you could not emulate some of the
standard Tcl commands...
I guess you could use all sorts of symbols:
ns_parseargs {+bool -opt {=choice x {x y z}}}
Hmm, is it a problem that you have to supply a default if you want to
enforce choosing oneof many? If the choices are contrained to x, y
and z but you also want to allow 'neither', couldn't you extend the
choices to 0, x, y, z, with 0 being the default?
Just throwing out ideas...
