Towards API signatures with optional parameters #216
Description
I think we should aim towards an API that supports for optional parameters. This is not a quick fix, so its an issue about aligning our intent.
Currently even an optional parameter added to a function signature makes people using our Rust/Java/JS libraries introduces a breaking change, because we typically introduce them as required parameters in the API. For example as below, if publisher was meant to be optional.
-public static native void init(String name, String version, String license, String path)
+public static native void init(String name, String publisher, String version, String license, String path)Change motivation
- It is easier to map implementations directly between library and CLI implementations if all implementations support optional parameters
- Non breaking changes when adding an optional parameter
- Lower maintenance burden when adding features
- Easy to overview code for functions that support many input parameters
Implementation strategy
In Python, this is supported by named parameters with default values for example, but in Rust, Java you probably need to adopt a builder pattern for this, and in JS/WASM as well while you may not need a dedicated builder.