[R-pkg-devel] Is there a better way ...?

[Duncan Murdoch]

On 21/10/2021 12:40 a.m., Andrew Simmons wrote:
> I think the simplest answer is to store the variable in the functions
> frame. I'm assuming here that the only plot.foo needs access to .fooInfo,
> if not this can be changed.
> 
> 
> plot.foo <- function (...)
> {
>      .fooInfo
> }
> environment(plot.foo) <- new.env()
> evalq({
>      .fooInfo <- NULL
> }, environment(plot.foo))
> 
> 
> Make your function, and do whatever you need with .fooInfo within said
> function. Whenever you previously updated .fooInfo in the global
> environment, update .fooInfo in plot.foo environment instead.
> Also, because .fooInfo is not stored in the package's frame, it won't be
> locked when the namespace is sealed. If you created it at the toplevel,
> that would create some issues. But this works fine.

I agree with the final result, but I'd write the code differently:

plot.foo <- local({

   .fooInfo <- NULL

   function (...) { ... }
})

creates an environment, puts .fooInfo into it with value NULL, then 
creates a function with that environment attached and returns it.

I think Andrew's approach will work, but changing a function's 
environment always worries me.  Using local(), the function assigned to 
plot.foo never has a different environment than the one it ends up with 
(and I don't need to remember how evalq() works).

Duncan Murdoch



> On Thu, Oct 21, 2021 at 12:29 AM Rolf Turner <r.turner using auckland.ac.nz>
> wrote:
> 
>>
>> I have a plot method (say plot.foo()) that I want to be able to call so
>> that if argument "add" is set equal to TRUE, then further structure will
>> be added to the same plot.  This is to be used *only* in the context in
>> which the plot being added to was created using plot.foo().
>>
>> [Please don't ask me why I don't do everything in a single call to
>> plot.foo().  There *are* reasons.]
>>
>> In order to make sure that the "further structure" has the appropriate
>> form, the call to plot.foo(...,add=TRUE,...) needs to access information
>> about what was done in the previous call to plot.foo().
>>
>> Initially I tried to effect this by creating, in a call of the form
>> plot.foo(...,add=FALSE,...), an object, say ".fooInfo", in the global
>> environment, and then having the call plot.foo(...,add=TRUE,...)
>> access the necessary information from ".fooInfo".
>>
>> It all worked OK, but when I built my package for Windoze, using
>> win-builder, I got a note of the form:
>>
>>> NOTE
>>> Found the following assignment to the global environment:
>>> File 'pckgename/R/plot.foo.R':
>>>    assign(".fooInfo", fooInfo, pos = 1)
>>
>> I thought uh-oh; CRAN will kick up a stink if/when I submit my package.
>>
>> I think I've figured out a work-around using tempfile().  There
>> are difficulties in that tempfile() creates unique names by tacking
>> on an alpha-numeric string such as "38348397e595c" to the file name
>> that I specify, so the call to plot.foo(...,add=TRUE,...) cannot know
>> the *exact* file name.  I think I can get around that by grepping on
>> "fooInfo" in list.files(tempdir()).  I also need to make sure that
>> I unlink() any old instances of files in tempdir() with the string
>> "fooInfo" in their names before creating a new instance.  Elsewise
>> ambiguities will ensue.
>>
>> As I say --- I think this can all be made to work.  But ....
>> Am I missing some "obvious" strategy?  I.e. is there a
>> better/simpler/less convoluted way of handling this problem?
>>
>> Grateful for any pearls of wisdom.
>>
>> cheers,
>>
>> Rolf Turner
>>
>> --
>> Honorary Research Fellow
>> Department of Statistics
>> University of Auckland
>> Phone: +64-9-373-7599 ext. 88276
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>