Some programming languages (e.g. Python) have support for keyword arguments, in addition to only ordered arguments. Furthermore, in Python at least, one can have a function with keyword only arguments, which can happen if an argument follows the varargs *args syntax, or in general for the **kwargs syntax. In either situation, the name of the parameter must be given along with the intended value.
SciJava Ops currently does not have a feature like this, but it could. Here is one possible syntax:
Img image = ...;
double sigma = ...;
Img result = ...;
Computers.Arity2<Img, Double, Img> gaussOp =
ops.op("filter.gauss")
.input("image", image)
.input("sigma", sigma)
.output(result)
.computer();
In the example above, the image and sigma parameters are individually given by separate .input(name, value) calls. A big advantage of this design is that it preserves the type safety offered by Ops. A downside is that the OpBuilder infrastructure would need to expand a lot to accommodate it. Another difficulty is that the op matching engine is currently fully built around the idea of ordered parameters, and it would need refactoring to support op requests with unordered+named inputs. But all of that could certainly be done with effort.
This goal of supporting op matching by named inputs would make it more elegant to wrap such Python functions into Ops. But even with it in place, Ops does not support varargs and might never do so, since it weakens type safety.
Some programming languages (e.g. Python) have support for keyword arguments, in addition to only ordered arguments. Furthermore, in Python at least, one can have a function with keyword only arguments, which can happen if an argument follows the varargs
*argssyntax, or in general for the**kwargssyntax. In either situation, the name of the parameter must be given along with the intended value.SciJava Ops currently does not have a feature like this, but it could. Here is one possible syntax:
In the example above, the
imageandsigmaparameters are individually given by separate.input(name, value)calls. A big advantage of this design is that it preserves the type safety offered by Ops. A downside is that theOpBuilderinfrastructure would need to expand a lot to accommodate it. Another difficulty is that the op matching engine is currently fully built around the idea of ordered parameters, and it would need refactoring to support op requests with unordered+named inputs. But all of that could certainly be done with effort.This goal of supporting op matching by named inputs would make it more elegant to wrap such Python functions into Ops. But even with it in place, Ops does not support varargs and might never do so, since it weakens type safety.