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 <plumm...@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}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
