On Fri, Oct 31, 2014 at 9:26 PM, Martin Morgan <mtmor...@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@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
[...]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
