Am 28.05.2005 um 14:10 schrieb Stephen Deasey:
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?
I do but I do not care. It is the new functionality and
it has to be learned. Furthermore it is compatible to
usual Tcl syntax and is "natural" in the way it uses nested
lists. Admitently, it can grow complex, but the task ain't
simple anyway.
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?
I also thought about using the first char as the type-selector
but it becomes weird if you are about to introduce other type-checking
like "int", "wide", "ascii", "print" (more generally, [string is...]
type of checks). Pretty soon you're out of signs and it is not very
illustrative/readable:
+bool -opt =choice ?string &int
Hm... I do not think this will be very user-friendly...
Although the "user-friendliness" is not my first objective, it HAS
to be somehow "readable".
Zoran
