8

I'm just thinking out loud about this one. So far I was saving all package-specific settings in options. I have some experience with ReferenceClasses (thanks to Rook), and I've seen that knitr uses RC to save package-specific staff. I'd like to know more about pros/cons of both approaches. Or maybe you'd like to recommend another approach (e.g. sourcing R file located in getwd() on startup, much like devtools and .Rpackages)?

Ideas?

aL3xa
  • 35,415
  • 18
  • 79
  • 112
  • 3
    The devtools use case is slightly different - it needs to maintain options across sessions, not just within a session. – hadley Mar 28 '12 at 19:27
  • Maybe I am a version behind, but in knitr 0.4 I just see use of environments and no ReferenceClasses. – Dirk Eddelbuettel Mar 29 '12 at 01:01
  • well... what do you know... =) It's my speak-before-think syndrome again! Or is it just do-not-think syndrome? – aL3xa Mar 29 '12 at 11:14
  • Is there actually some kind of "solution" to this question/thinking? I am having the same issue and I am not sure what to choose. – drmariod Nov 11 '15 at 12:37

1 Answers1

8

You can also store options in an environment stored at the top-level of your package. That may be closest to options() use, while avoiding the global variable.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725