Forum OpenACS Development: ad_proc - Behaviour using named parameters

Hi all,
just stumbled upon this:

# -----------------------------------------------------------------------
ad_proc -public test_par {
{ -par_1 "1" }
} {
} {
return $par_1
}
ns_return 200 text/html [test_par -par_2 2]

# -----------------------------------------------------------------------

returns - as expected - : "invalid non-positional argument '-par_2', valid are : -par_1; "

but:

# -----------------------------------------------------------------------
ad_proc -public test_par {
{ -loginpage_p 1 }
} {
} {
return $loginpage_p
}
ns_return 200 text/html [test_par -loginpage 2]
# -----------------------------------------------------------------------

returns: "2"

Is this considered to be desired behavior of ad_proc?

Collapse
Posted by Brian Fenton on
Hi Klaus

This is a known feature of ad_proc (one I personally don't like) called Boolean named parameters. See the documentation here with the example using flush_p https://openacs.org/api-doc/proc-view?proc=ad_proc

Brian

Collapse
Posted by Klaus Hofeditz on
Hi Brian,
thanks for the clarification.

Looking at the documentation I'd say that this feature would require the declaration of the var as 'boolean'. Never mind, knowing this I can work around it.

Cheers
Klaus

Collapse
Posted by Brian Fenton on
Hi Klaus

actually I have to take back what I said. I don't understand what's causing your proc's behavior. I do have this idea in my head that certain parts of OpenACS treat "foo_p" and "foo" as the same, but I can't remember where I read that (apart from the boolean named variables, which is not what is happening in your case).

Sorry for the confusion.
Brian

Collapse
Posted by Gustaf Neumann on
The behavior is not unexpected. Since a while, OpenACS uses the c-implemented argument parser of xotcl2/nsf, when it is installed. This argument parser is many times faster than the old Tcl-only implementation (for longer argument lists) and uses less memory. The c-based parser follows the standard Tcl mechanisms for parsing options, which may be abbreviated, as long as the abbreviation is unambiguous (see e.g. [1,2]).

The observed behavior above has nothing to do with the "_p" magic of Boolean switches in OpenACS, but it is just about abbreviations. In the following code, two switches are provided stating with the same prefix. As long the provide abbreviation is unique, the abbreviation is accepted.

ad_proc -public test_par {
    { -foooo 1 }
    { -foo2  1 }
} {
} {
   return $foooo
}
ns_return 200 text/html [test_par -foo 2]
In the call in the last line the abbreviation is not unique, therefore an exception with the message "the provided argument -foo is an abbreviation for -foooo and -foo2" is raised.

Abbreviations do not harm the code: all calls which are valid without abbreviations are as well valid with abbreviations, since the variable names are always the full names. The c-based argument parser supports as well more functionality like configurable value checking (providing more safety), but that is not used in OpenACS.

-gn

[1] Abbreviations in tk https://www.tcl.tk/man/tcl/TkCmd/options.htm
[2] Tcl library function https://www.tcl.tk/man/tcl8.5/TclLib/GetIndex.htm

Collapse
Posted by Klaus Hofeditz on
Thanks for your exhaustive and detailed response. It's very much appreciated!