I suppose this is a trivial question, but I find this annoying.
Is there an easy was of passing a switch non-positional argument to another procedure based upon the value provided to the calling procedure? For example, if both p1 and p2 take a switch non-positional argument -sw, and p2 calls p1, but wants to forward along the state of the -sw parameter, how is that best expressed. The straightforward approach - testing the value of -sw and then using the correct invocation - is ugly, and subject to combinatorial explosion. To avoid the combinatorial problems, and make it a little cleaner, I can collect the options in a list and then make the call (using an eval). This works, and is certainly cleaner, but it still seams that there should be an easier way to pass the value along; passing other options along is simply a matter of calling the option and providing the current value. The example below shows these options:
Object obj
obj proc p1 {{-sw:switch 0} {-opt 1}} {
puts "sw: $sw"
puts "opt: $opt"
}
obj proc p2 {{-sw:switch 0} {-opt 1}} {
if { $sw } {
my p1 -sw -opt $opt
} else {
my p1 -opt $opt
}
}
obj proc p3 {{-sw:switch 0} {-opt 1}} {
set options [list -opt $opt]
if { $sw } { lappend options -sw }
eval my p1 $options
}
Is there a better way to do this?
Thanks,
Kurt
Kurt,
passing around the actual values of the non-positional arguments with next or with a forwarder is already very conveniant, but this was not your question.
Passing unary non-pos arguments to some explicit method invocations is some typing work, but straightforward. Passing a switch is painful. Your example can be made somewhat shorter
eval my p1 [expr {$sw? "-sw" : ""}] [list -opt $opt]
list is needed to protect the value of opt, if it contains e.g. a $, spaces etc. But still, the preceding eval reminds me on the days of otcl and does not win a beauty contest.
For your example, i would tend to use boolean non-pos-args instead. We introduced the 0-argument switch mostly for oacs, which uses a similar construct already for it's ad_proc. When one defines in xotcl a public/private method with boolean, as in
SomeClass method -private true foo {x y } ....
this looks rather stupid compared to
SomeClass method -private foo {x y } ....
However, in many other situations, the notation with the boolean argument as in
obj -someflag on
or
obj -debug true
looks from the aesthetical point of view quite ok to me.
-gustaf neumann
-
Gustaf Neumann -
Kurt Stoll