option validation

[moodymudskipper]

I'm not sure about this dcf strategy because it implies :

• potential duplication of code (if user has checking code in package already)
• checking code that is not tested and might not be aligned with actual expected values (though it's on the maintainer)
• opt specific effort, though no dependency

Maybe maintainer should define checking functions for options, and those would be detected ? how though ? strict naming or function/argument ? complex heuristics ?

For instance in {flow} I might have something like :

# checking "flow.svg" option
check_svg_opt <- function(value) stopifnot(is.logical(value))

I can use it in my own package, and {opt} would find it. Can we think of an heuristic general enough so that a user wouldn't have to think about conventions too hard, just write a check function for any option and we'd pick it up ?

A lot of options are defined as default args so we might pick single argument functions that are called on the relevant arg for those ?

We might also get it from the documentation of those args, if it's formatted like "A boolean. Whether to ..." or "Character, name of the ...", that's a wide net

I still like the idea that the maintainer may help {opt} not do its complex (and unavoidably costly and brittle to an extent) heuristics.

[moodymudskipper]

The idiom if (getOption("foo")) is evidence that we expect a boolean

[moodymudskipper]

The automated stuff seems to be feature bloat.

In the case above we can use check_svg_opt() in the dcf so no need for code duplication. The one thing we need to do is :

• [ ] evaluate the dcf conditions in the package's namespace

I believe for now it's evaluated in the local env so we wouldn't recognise an unexpected check_svg_opt()