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.tur...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
