From jhallman at frb.gov  Tue Dec 12 16:51:43 2006
From: jhallman at frb.gov (jhallman at frb.gov)
Date: Tue, 12 Dec 2006 10:51:43 -0500
Subject: [Rd] Documenting revised functions
Message-ID: <20061212155143.99F845362D@mail.rsma.frb.gov>

I am running into some problems with the way R CMD check looks at
documentation. 

The stats::filter function returns a time series with class "ts" or
c("mts", "ts") if it is multivariate.  I have created a more capable
time series class called "tis" as part of my fame package.  My package
redefines filter() as a generic function, and has filter.default() call
the stats::filter function.  The filter.tis() function calls
filter.default() and turns the result into a tis series. 

My problem is how to document this.  Since my package exports filter(),
it needs an \alias{filter} in an Rd document, otherwise R CMD check
complains about an undocumented object.  However, when I fix that by
having an Rd document with \alias{filter} in it, help(filter) puts up
the too-small tk_select.list() menu I've complained about before to ask
me which help document I want, the package::fame one or the
package::stats one.  And because the generic filter() is now

filter <- function (x, ...) UseMethod("filter")

the filter.default() function also has to have a useless ... argument in
it to avoid this warning from R CMD check:

* checking S3 generic/method consistency ... WARNING
filter:
  function(x, ...)
filter.default:
  function(x, filter, method, sides, circular, init)

Of course, if I add the ... argument to filter.default(), I then have to
add an \item{\dots} to its help document, wherein I get to explain to
the mystified reader that the argument is ignored.

Am I missing something here?  How should I go about documenting my
generic filter() and its methods?

Jeff



[Rd] Documenting revised functions
jhallman at frb.gov