title: make S3 generic function name available when adding new method, roxygen2
body: <p>I wrote a new S3 method in an R package, for a generic function 'NSE' from package 'hydroGOF', and I am unsure how to (let roxygen2) formulate the NAMESPACE.</p>
  
  <p>Here is an example. 'NSE' has two required arguments, 'sim' and 'obs'.</p>
  
  <pre><code>#' @export
  #' @importFrom hydroGOF NSE NSE.default
  NSE.foo &lt;- function(sim, obs, na.rm = TRUE, ...) {
    NSE.default(as.numeric(sim), as.numeric(obs), na.rm = TRUE, ...)
  }
  </code></pre>
  
  <p>When i build the package, these rows are added to NAMESPACE:</p>
  
  <pre><code>S3method(NSE,foo)
  importFrom(hydroGOF,NSE)
  importFrom(hydroGOF,NSE.default)
  </code></pre>
  
  <p>My problem is now, that the (generic) function 'NSE' is not available when i load my package, and R throws an 'unknown function' error:</p>
  
  <pre><code>&gt; library(mypackage)
  &gt; s &lt;- rnorm(10)
  &gt; o &lt;- rnorm(10)
  &gt; class(s) &lt;- "foo"
  &gt; class(o) &lt;- "foo"
  &gt; NSE(sim = s, obs = o)
  Error: could not find function "NSE"
  </code></pre>
  
  <p>... unless I load 'hydroGOF' first, i which case it does what i want:</p>
  
  <pre><code>&gt; library(hydroGOF)
  &gt; NSE(sim = s, obs = o)
  [1] -1.195519
  </code></pre>
  
  <p>I understand that this has to do with hydroGOF functions being loaded but not attached when I attach my package, but I don't know how to solve this. There is no '@depends' roxygen directive which i could use rather than '@importFrom', or?</p>
  
  <p>I suspect I arrived at "scenario 4" outlined by Hadley on <a href="http://r-pkgs.had.co.nz/namespace.html#exports" rel="nofollow">his R-package/Namespace page</a>:</p>
  
  <blockquote>
    <p>A method for a generic in a suggested package. Namespace directives must refer to available functions, so they can not reference suggested packages. It’s possible to use package hooks and code to add this at run-time, but this is sufficiently complicated that I currently wouldn’t recommend it. Instead, you’ll have to design your package dependencies in a way that avoids this scenario.</p>
  </blockquote>
  
  <p>... but i don't know how to avoid it. :)</p>
  
  <p>Any help appreciated. Thanks!</p>