Alternative way of passing arguments to methods about constructive HOT 7 CLOSED

Thanks. I don't understand "extra work for NSE".

from constructive.

Here is a POC:

# krlmlr said this needed the ellipsis but I'm not sure why
# this is exported, documented, and referenced in `?construct`
opts_function <- function(trim = NULL, as.function = FALSE, zap_srcref = FALSE, construct_env = FALSE) {
  # insert check and processing of args here
  structure(
    class = c("constructive_options", "constructive_options_function"),
    list(
      trim = trim, 
      as.function = as.function, 
      zap_srcref = zap_srcref, 
      construct_env = construct_env
    )
  )
}

fetch_opts <- function(suffix, ...) {
  class <- paste0("constructive_options_", suffix)
  Filter(function(x) inherits(x, class) ,list(...))[[1]]
}

construct_idiomatic.function <- function(x, ...) {
  args <- fetch_opts("function", ...)
  args
  # actual logic, we can pass the dots without further processing
}

construct <- function(x, ...) {
  if (is.function(x)) construct_idiomatic.function(x, ...)
}

construct(ave, opts_function(zap_srcref = TRUE))
#> $trim
#> NULL
#> 
#> $as.function
#> [1] FALSE
#> 
#> $zap_srcref
#> [1] TRUE
#> 
#> $construct_env
#> [1] FALSE
#> 
#> attr(,"class")
#> [1] "constructive_options"          "constructive_options_function"

How to use a template ?

• we can build a list of opts_*()calls and feed them to construct() as a general template using !!!
• or we can use a construct_template() helper so users don't need to speak rlang.

How to modify options and propagate a new value ?

We can copy args and feed it right before the forwarded dots and the updated version will be considered.

from constructive.

I don't understand "extra work for NSE".

@krlmlr It doesn't matter for this package but I was thinking that in general to use the approach used above in my POC, having NSE arguments to opts_* functions would require a bit of rlang enquo magic. We could still make it work nonetheless.

from constructive.

The ellipsis in the front enforces the use of named arguments, and provides an opportunity for better error messages and for renaming options.

We could also do a separate help page for each option constructor.

from constructive.

The ellipsis in the front enforces the use of named arguments, and provides an opportunity for better error messages and for renaming options.

Right I forgot this detail thanks

We could also do a separate help page for each option constructor.

Yes I had this in mind, I meant exported, documented on its own, and linked in ?construct

from constructive.

fetch_opts() above is incorrect because we need defaults when no arg has been passed, something like this should work:

fetch_opts <- function(suffix, ...) {
  class <- paste0("constructive_options_", suffix)
  Filter(function(x) inherits(x, class) ,list(...))[[1]] %||% match.fun(paste0("opts_", suffix))()
}

from constructive.

Regarding the template, I now believe it should be a separate argument template = getOption("constructive_opts_template").

This simplify the handling of the ..., always unnamed, always inherits from constructive_options, never provide the same option helper twice.

This way the user can personalise once for all the way they want construct() to work, this function should be quick and easy to call and it should be easy to save preferences.

template is a simple list.

We should be able to integrate general options and waldo options to the template too, to maybe these should be wrapped into opts_* functions, maybe with a different name structure to avoid conflicts.
Note that since we don't fail anymore by default with check=NULL, the waldo options are not as useful anymore so it's ok to make them a bit less easy to toggle. We might leave data, check and one_liner out of the template, and have a opts_general() for the rest.

arguments passed to ... will override the template.

from constructive.