On 5/27/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 27.05.2005 um 11:34 schrieb Stephen Deasey:
>
> > Where we left the discussion last time is how to deal with type
> > checking. Boolean switches and range values are basically just forms
> > of type checking.
>
> Hmm.... what I understood here was data-type checking as in
> integer/string type of thing.
>
> Under boolean support, I actually ment *absence* or *existence*
> of the option. I do not know how I could achieve this now, unless
> I say:
>
> ns_parseargs {{-boolean 0} args}
>
> but this is also half-baked.
Right, but the option list is type checking. One of the syntaxes we
talked about was:
ns_parseargs {-a:int -b:bool -s:switch} $args
So the boolean switch could use the type syntax. I'm not desperate
for [string is ...] checks so leaving that out will certainly make
life easier, but we still have to think about the syntax for
specifying types as seems we need it anyway...
> OK, lets think about type-checking. I would definitely say that
> boolean type-checking (as described above) should be in.
> The same for option-lists. Those two are most commonly found
> and needed. Other type of checking would not be needed.
> So, if I say:
>
> ns_parseargs {-a args}
>
> then anything what is given to "-a" should be accepted as is.
> Something like "string is ..." checking should be left to the
> programmer.
>
> I believe that underlying C-api already does the above, or?
You mean checking for integers etc.? The C API does do this (has to,
it's C!), but the Tcl wrapper doesn't use it. It was easier to define
a new Ns_ObjvSpec proc to handle all Tcl args than to massage the arg
spec into what the C API expects. I don't know whether it makes sense
to try and use the underlying C stuff or not.
> >
> > Depending on how type checking is implemented, then the syntax of an
> > arg specification may change. You may or may not end up pulling your
> > hair out later if you change all your code to use ns_proc now... :-)
> >
>
>
> Right. Lets fix this now. We can talk about the syntax when/if we
> agree on the scope of the implemented type-checking (as above).
> Deal?
Sure. How would you specify an option list? And would there be the
two types that the C API supports, the choose 1 and the choose 1 or
more? For the choose 1 or more the result should probably be an array
(where the C implementation logically OR's bits).
So, with an option of -thingy where you can choose 1 or more of foo,
bar or baz, specifying -thingy {foo bar} would result in foo(bar) and
foo(baz) being set.
Maybe it would look something like this:
ns_parseargs {{-thingy:either {foo bar baz}}} $args
ns_parseargs {{-thingy:either {foo bar baz} foo} $args ;# foo is default
ns_parseargs {{-thingy:any {foo bar baz}}} $args
ns_parseargs {{-thingy:any {foo bar baz} {foo bar}} $args
i.e. either and any would have to be at least a two element list, the
optional third element being the default value.
