From wdunlap at tibco.com  Sat Nov  1 01:16:22 2014
From: wdunlap at tibco.com (William Dunlap)
Date: Fri, 31 Oct 2014 17:16:22 -0700
Subject: [Rd] Options that are local to the package that sets them
In-Reply-To: <CABtg=KmCrX1G3K8BxdeJsHvMpMhwoscZ0ExY4_ga9614oYB=KQ@mail.gmail.com>
References: <CABtg=KmCrX1G3K8BxdeJsHvMpMhwoscZ0ExY4_ga9614oYB=KQ@mail.gmail.com>
Message-ID: <CAF8bMca9j3w2T7Uu1pDx97uK=k0aP4jva6qwCT_rhHS5KfayRg@mail.gmail.com>

You can put the following 3 objects, an environment and 2 functions
that access it, in any package that need some package-specific
storage (say your pkgB1 and pkgB2).
   .pkgLocalStorage <- new.env(parent = emptyenv())
   assignInPkgLocalStorage <- function(name, object) {
       .pkgLocalStorage[[name]] <- object
   }
   getFromPkgLocalStorage <- function(name, object) {
       .pkgLocalStorage[[name]]
   }
Leave the environment private and export the functions.  Then a user can
use them as
   pkgB1::assignInPkgLocalStorage("myPallete", makeAPallete(1,2,3))
   pkgB2::assignInPkgLocalStorage("myPallete", makeAPallete(5,6,7))
   pkgB1::getFromPkgLocalStorage("myPallete") # get the 1,2,3 pallete

If only one of pkgB1 and pkgB2 is loaded you can leave off the pkgBn::.

A package writer can always leave off the pkgBn:: as well.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Oct 31, 2014 at 4:34 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
> Dear All,
>
> I am trying to do the following, and could use some hints.
>
> Suppose I have a package called pkgA. pkgA exposes an API that
> includes setting some options, e.g. pkgA works with color palettes,
> and the user of the package can define new palettes. pkgA provides an
> API to manipulate these palettes, including defining them.
>
> pkgA is intended to be used in other packages, e.g. in pkgB1 and
> pkgB2. Now suppose pkgB1 and pkgB2 both set new palettes using pkgA.
> They might set palettes with the same name, of course, they do not
> know about each other.
>
> My question is, is there a straightforward way to implement pkgA's
> API, such that pkgB1 and pkgB2 do not interfere? In other words, if
> pkgB1 and pkgB2 both define a palette 'foo', but they define it
> differently, each should see her own version of it.
>
> I guess this requires that I put something (a function?) in both
> pkgB1's and pkgB2's package namespace. As I see it, this can only
> happen when pkgA's API is called from pkgB1 (and pkgB2).
>
> So at this time I could just walk up the call tree and put the palette
> definition in the first environment that is not pkgA's. This looks
> somewhat messy, and I am probably missing some caveats.
>
> Is there a better way? I have a feeling that this is already supported
> somehow, I just can't find out how.
>
> Thanks, Best Regards,
> Gabor
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



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