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
