Export filter in the NAMESPACE file *without copying it* in the R source code.
________________________________
From: Winston Chang [winstoncha...@gmail.com]
Sent: 19 June 2014 21:28
To: Martyn Plummer
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD check warning with S3 method
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<mailto: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<mailto:R-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:11}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
