Skip to content

Allow primary parameters to be optional #14

@gselzer

Description

@gselzer

There are good reasons for the removal of secondary parameters in this iteration of Ops

  • Lambda Ops cannot support secondary parameters
  • The current state of OpService.run() cannot currently support secondary parameters and would be slowed down if we were to provide support through that method
  • Removing secondary parameters will result in fewer lines of code

For these reasons it would be best to push towards the exclusive use of primary parameters. However this has one main drawback in that secondary parameters are associated with optional parameters: in the previous iteration of Ops primary parameters were never optional and should never be optional. The current strategy in solving this has been to:

  • Port the Op and make the optional parameter required.
  • Make a second lambda Op that just calls the main Op with a reasonable default for the optional parameter.

In many cases however this severely bloats the code base. In many cases, especially when the Ops are lambdas, this is not a big deal, however it can be problematic when there are multiple optional parameters and/or the Ops must be classes. For this reason it would be nice to allow primary optional parameters in such situations.

As of now the @Parameter annotation can be designated as required = false, however it is currently really only a placeholder. A current strategy is to designate optional parameters as required = false under the contract that the user will pass null for that parameter if they want the reasonable default. Then in the body of the op the developer would check that param:

if(param == null) param = reasonable_default;

This, however, feels lacking. It would be nice if the Op matcher was intelligent enough to be able to read those required = false annotations and be able to match a smaller-order function when the user so desires (i.e. if the user wants to match a Function3 with one optional parameter they can do so by asking the matcher for a BiFunction with the same name and same typing as the required params of that function). This could possibly be done with an OpTransformer.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions