[R-pkg-devel] attach

Ben Bolker bbo|ker @end|ng |rom gm@||@com
Mon Apr 6 16:59:22 CEST 2020


  Fair enough.  I'm going to derail/repurpose this thread to ask a
couple of questions about attach().

   I have often used with() for situations where I want to evaluate a
bunch of expressions with the elements of a parameter vector, e.g.
inside a gradient function for deSolve::ode().  However, I have found
this very hard to debug because (AFAIK) you can't debug-step through the
components of a with() expression.
  Potential solutions for this include

 1. attach(params); on.exit(detach(params))

  * this will be flagged by CRAN
  * I have found some really surprising (to me) precedence issues with
this _when used in a package context_ - it looks like the elements in
'params' are found _after_ built-in objects in R?? (I have to take some
time to make a MRE of this

  2. The zeallot package does 'unpacking' as with Python tuples.  I was
worried about dragging in tidyverse dependencies, but it looks like it
doesn't actually Import: anything.
   This doesn't quite do what I want, as I want to unpack using the
names in the object (which makes it look perfect for the attach() solution)


  Thoughts?

On 2020-04-06 10:49 a.m., Dirk Eddelbuettel wrote:
> 
> On 6 April 2020 at 08:38, Ben Bolker wrote:
> |   Just reply to the CRAN maintainers and explain this situation.  It¨s
> | slightly buried, but the e-mail you received does say:
> | 
> | > If you are fairly certain the rejection is a false positive, please reply-all to this
> | > message and explain.
> 
> True, but this misses the "Letter of the law" versus the "Spirit of the law".
> 
> It might be worth mentioning that use of attach() is seen, to find one poor
> analogy, pretty much like use of global variables these days. "Just because
> you could does not mean you should".
> 
> See e.g. one of the first google hits for 'r do not use attach' here:
> https://stackoverflow.com/questions/10067680/why-is-it-not-advisable-to-use-attach-in-r-and-what-should-i-use-instead
> 
> Dirk
>



More information about the R-package-devel mailing list