R devel - Oct 2014 - Options that are local to the package that sets them

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

On Fri, Oct 31, 2014 at 7: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.
>
Try the settings package.

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