[R-pkg-devel] [External] Re: Two packages with the same generic function

Tue, Jun 23, 2020 8:11 AM

On 23/06/2020 10:28 a.m., Viechtbauer, Wolfgang (SP) wrote:

I think you'd need to be more specific about the two packages before I 
would believe this is much of a problem.

If pkgA and pkgB both contain methods for the same generic, then they 
are probably working in the same problem domain, and already share many 
dependencies.  It seems it would be rare that pkgA's dependencies and 
pkgB's dependencies are both big sets that don't have a lot of overlap.

If it's only pkgB that has the big dependency set, then just put the 
generic in pkgA.  And if you really are in that rare case where they 
both have big non-overlapping dependency sets, then create a tiny pkgC 
to hold the generic.

On the other hand, if both packages were allowed to declare foo as a 
generic, and R should think of it as the same generic, confusion would 
follow:

Think about the case of the filter functions in stats and dplyr.  It's 
not a generic in stats, but obviously could be.  In stats, the name is 
used to talk about linear filtering on a time series. (There are several 
different representations of time series in R, so it might make sense 
for stats::filter to be a generic to allow it to work on all of them.)

In dplyr, the same name is used to describe subsetting a dataset.

Those are both valid uses of the word "filter", but they have nothing to 
do with each other.  It's perfectly reasonable to think that a user 
might want to do both kinds of filtering.  If stats::filter was a 
generic and someone wrote a method for dplyr::filter, clearly a call to 
stats::filter should not use that method. It's even possible that some 
package doing time series analysis in the tidyverse framework would want 
to have methods for both generics.

Duncan Murdoch

[R-pkg-devel] [External] Re: Two packages with the same generic function

Thread (20 messages)