Forum OpenACS Development: Re: ad_parameter deprecated in favor of parameter::get?

Collapse
Posted by Tom Jackson on

Andrew, tcl prcs, those defined with proc, have required parameters first, because they are passed in to the proc in order. Following that are parameters which have defaults defined for them:


proc my_proc { param1 param2 {param3 "a"} {param4 "b"} } {

    # do something

}

But I don't see what you are talking about WRT the string and clock commands. The order is:

  • command
  • subcommand
  • switches
  • required_positional_params
  • optional_positional_params

The string command does have a few switches which require a value, just like unix command switches. And the order is the same format as unix commands. There are no named parameters in unix commands.

In contrast, db_multirow, defined via ad_proc has optional switches, followed by unnamed positional params, followed by more optional switches, followed by a required 'code_block' param, followed by an optional param:


 db_multirow [ -local ] [ -append ] [ -extend column_list ]
  var-name statement-name sql 
  [ -bind bind_set_id | -bind bind_value_list ] code_block 
  [ if_no_rows if_no_rows_block ]

The final optional param has to be prefixed with a switch that has a distinct format, missing the beginning '-'.

There can always be good reasons for doing things this way, and I'm not passing judgement on the style. I think the procedure comes with enough documentation to quickly figure out how to use it. But it isn't like tcl or unix command style.

Tom, "clock format" with it's "-format $format_string" syntax, stuck on the end where you say optional positional params would go, does not fit into your above model at all. Tcl is ad-hoc and arbitrary on this. Even in the Tcl core, the various commands and procedures follow no firm style guidelines when it comes to order or style of arguments to functions - which seems ok to me.

db_multirow, ah, good point, I'd forgotten you could define complicated syntax like that with ad_proc. (Never had any reason to use it myself.) Ok, so then IMO, when it comes to the style of passing arguments to procedures, OpenACS and Tcl are both ad-hoc.

Of course, this all fits with (and stems from) the basic free-form nature of the Tcl syntax That, roughly, the first argument on a line is always a command, and it's up to that command to do whatever the heck it wants with all the rest of the arguments, imposing any special syntax it may care to, etc.