Forum OpenACS Development: passing arguments, ad_proc definitions

Is there a way to pass multiple named arguments in ad_proc definitions without explicitly defining them.

For example, if qf_test is defined as:

ad_proc -public qf_test {
} {
this tests ad_proc use of named arguments, and whether or not they need to be defined
} {
if { ![exists arg1] } {
set arg1 "no arg1 parameter passed"
}
return $arg1
}

I want to be able to invoke it with any valid named parameter, such as:

qf_test -arg1 value1 -arg2 value2 -argN valueN

where ad_proc passes the arguments as a list of named argument/value pairs.

Does a feature like this already exist in OpenACS, or do I need to pass the pairs as a list?

An interesting solution, Dave.

How does one pass the argv values through an ad_proc definition?

As

ad_proc -public qf_test {
argv
} {
...

?

If I understand correctly, get_opts is passing a list of named parameters out of a procedure's namespace, to the namespace that called the procedure.

I'm looking to pass an unspecified set of named parameters that is provided with a call, to the namespace within the procedure. For example:

qf_test -foo value1 -bar value2 -fooo valueN -barr valueM

Based on get_opts and your answer, I'm going to assume my question isn't an option to be defined via ad_proc, and that I should use upvar instead. This makes sense, since extra care needs to be taken so that any named parameter that is passed does not interfere with the code in some sort of unplanned value injection method etc.

Thank you,

Torben

I appreciate your input, Dave.

I'm using something like it for private procs of a package under development.

The functionality needs to be a part of ad_proc, because the public designated procs are planned to be repeatedly called via manually coded (typed) tcl files, and so should be as intuitive and convenient as possible.

Since ad_proc understandably doesn't appear to have the feature, it seems the most dynamic way (that doesn't add extra constraints) is to pass the named parameters as a list for these public designated cases:

qf_test \[list -arg1 value -arg2 value -arg3 value \]

or

qf_test $arg_list

Thank you, again,

Torben

Apparently, this is something conceptual within my mind that I revisit now and then (and hopefully didn't post about before). It's the idea that a proc can have any number of ordered parameters. TCL doesn't have this at the procedure definition, but then what language does? (rectorial question)

Using standard proc format, the max number of parameters can be designated with empty string as a default.

Actually, this discussion has been fruitful.

Example:

ad_proc -public qf_test {
{named_param_1 ""}
{named_param_1_value ""}
{named_param_2 ""}
{named_param_2_value ""}
...
pattern continued to max number of parameters
} {

Thank you for the exercise, Dave.

cheers,

Torben

Yeah, that's the idea, Dave, but this will be used for fringe cases (values with negative numbers, values as lists etc.), and from what I understand, the args breaks with at least the negative numbers.. If I assume named parameter pairs have exactly 2 ordered positions, then 40 named parameter pairs (without complexity of dashes) can be defined:

ad_proc -public qf_test {
{arg1 ""}
{arg2 ""}
...
{arg15 ""}
{arg80 ""}
} { ...

This works regardless of value types (except delineating the special case of empty string versus no value), although it is a bit bulky/clunky. If only there is a shorthand for that..

Actually, one can differentiate between an empty value and a nonexistent value using this technique. An empty value is when a named parameter is passed and it's paired value is empty. A named parameter that is not passed *is* nonexisting.