[R-pkg-devel] Is there a better way ...?
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 at 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel