accept dedicated types for parameters instead of strings #5
Description
According to the README, the current user interface has OptimizeParameters accept arbitrary strings for some of the parameters. This is usually problematic because of the possibility of typos and the requirement to check for typos in the implementation for safety.
An approach that would be automatically safer would be to rely on dispatch for typo-checking: instead of accepting arbitrary strings you could define a type (each possibly a Union of several other types) for each method parameter, and annotate the parameter with this type so the correct type would be required for the function invocation to succeed.
This approach would also allow for possibly tidier documentation, as it'd be possible to attach a doc string to each defined type (and/or constructor).
In a sense there are two approaches (may be combined/mixed variously): a different type for each specific configuration, or one type for all configurations. E.g.:
One type for all configs, for allowing better type stability:
module Options
module SolveMod
# or just use `@enum`, or one of the enum packages
struct O # not part of the public interface
o::Int
end
const both = O(1) # public interface
const bbc = O(2) # public interface
const ilp = O(3) # public interface
end
# other options
endA type for each config, for allowing more specialization:
module Options
module SolveMod
struct Both end # public interface
struct BBC end # public interface
struct ILP end # public interface
const U = Union{Both,BBC,ILP} # not part of the public interface
end
# other options
end