[Rd] Options that are local to the package that sets them

[Gábor Csárdi]

On Fri, Oct 31, 2014 at 9:26 PM, Martin Morgan <mtmorgan at fredhutch.org> wrote:
[...]
> You'll need pkgA to be able to know that pkgB1's invokation is to use
> pkgB1's parameters, so coupling state (parameters) with function, i.e., a
> class with methods. So a solution is to use an S4 or reference class and
> generator to encapsulate state and dispatch to appropriate functions, E.g.,
>
>   .Plotter <- setRefClass("Plotter",
>       fields=list(palette="character"),
>       methods=list(
>         update(palette) {
>             .self$palette <- palette
>         },
>         plot=function(...) {
>             graphics::plot(..., col=.self$palette)
>         }))
>
>   APlotter <- function(palette=c("red", "green", "blue"))
>       .Plotter(palette=palette)
>
> PkgB1, 2 would then
>
>   plt = APlotter()
>   plt$plot(mpg ~ disp, mtcars)
>   plt$update(c("blue", "green"))
>   plt$plot(mpg ~ disp, mtcars)
>
> or
>
>   .S4Plotter <- setClass("S4Plotter", representation(palette="character")
>   S4Plotter <- function(palette=c("red", "blue", "green"))
>   s4plot <- function(x, ...) graphics::plot(..., col=x at palette))
>
> (make s4plot a generic with method for class S4Plotter to enforce type).
>
> Seems like this interface could be generated automatically in .onLoad() of
> pkgA, especially if adopting a naming convention of some sort.

Yes, I think this works, and all three of us came to essentially the
same solution.
Unfortunately, this solution also requires putting the whole pkgA API
inside such a class, otherwise the pkgA functions will not find the
right settings.

Thanks again!
Gabor

[...]