Oh, I forgot to mention I tried a few other variations:


=================
Re-export dplyr::filter:
  filter <- dplyr::filter

NAMESPACE has:
  S3method(filter,test)
  export(filter)
  importFrom(dplyr,filter)

Then the filter.test method from s3methodtest doesn't seem to get
registered properly:

library(s3methodtest)
filter(structure(list(), class = "test"))
# Error in UseMethod("filter") :
#  no applicable method for 'filter' applied to an object of class "test"

=================
Create a brand new filter generic:
  filter <- function (.data, ...) UseMethod("filter")

NAMESPACE has:
  S3method(filter,test)
  export(filter)
  importFrom(dplyr,filter)

Then loading dplyr will cause its dplyr::filter generic to block methods
registered for: s3methodtest::filter:

library(s3methodtest)
filter(structure(list(), class = "test"))  # OK
library(dplyr)
filter(structure(list(), class = "test"))
# Error in UseMethod("filter") :
#  no applicable method for 'filter' applied to an object of class "test"


So either way, it doesn't work.

-Winston




On Thu, Jun 19, 2014 at 12:15 PM, Martyn Plummer <plummerm@iarc.fr> wrote:

> When you provide a method for a generic function imported from another
> package then the generic must be on the search path. Otherwise if a user
> types "filter" the dispatch to "filter.test" will never occur.
>
> What is happening here is worse because "filter" is a non-generic
> function in the stats package which is always on the search path.
>
> As you note, using "Depends: dplyr" works because it attaches dplyr to
> the search path before your test package is loaded. If you use "Imports"
> instead then you need to re-export the generic "filter" function from
> your package namespace.
>
> You will also need to document the generic function in your package. A
> minimal functioning help page that cross-references to the dplyr package
> should be sufficient (Note that S4 generics get a free pass here and do
> not need to be documented when re-exported, but S3 generics do).
>
> Martyn
>
> On Tue, 2014-06-17 at 14:21 -0500, Winston Chang wrote:
> > I'm getting an R CMD check warning with a package (call it package A)
> > that defines an S3 method but not the generic. The generic is defined
> > in another package (package B). Package A imports the S3 generic from
> > B. And there's one additional detail: the generic overrides a function
> > in the stats package.
> >
> > I've created a minimal test package which reproduces the problem:
> >   https://github.com/wch/s3methodtest
> >
> > In this case:
> > - the package imports dplyr, for the dplyr::filter S3 generic
> > - the package defines a S3 method filter.test
> > - it imports dplyr, which defines a filter S3 generic
> >
> > The warning doesn't occur when package dplyr is in Depends instead of
> > Imports. It also doesn't occur if the method is for a generic that
> > does not override an existing function like stats::filter. For
> > example, if instead of filter.test, I define select.test
> > (dplyr::select is also an S3 generic), then there's no warning.
> >
> > This warning seems incorrect. Is this a bug? I'm interested in
> > submitting the package to CRAN soon, so any advice on what to do is
> > appreciated.
> >
> > Thanks,
> > -Winston
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> -----------------------------------------------------------------------
> This message and its attachments are strictly confiden...{{dropped:12}}

