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

[Duncan Murdoch]

On 23/06/2020 10:28 a.m., Viechtbauer, Wolfgang (SP) wrote:
> Still, if pkgA imports the generic from pkgB, then installing pkgA installs pkgB and all of its dependencies (Depends and Imports). Which of course makes sense (as otherwise pkgB cannot be installed). But all of this just for importing
> 
> foo <- function(x, ...)
>     UseMethod("foo")
> 
> from pkgB.

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


> 
> Best,
> Wolfgang
> 
>> -----Original Message-----
>> From: R-package-devel [mailto:r-package-devel-bounces using r-project.org] On
>> Behalf Of Duncan Murdoch
>> Sent: Tuesday, 23 June, 2020 12:25
>> To: Guido Schwarzer; r-package-devel using r-project.org
>> Subject: Re: [R-pkg-devel] [External] Re: Two packages with the same generic
>> function
>>
>> On 23/06/2020 4:22 a.m., Guido Schwarzer wrote:
>>> Am 23.06.20 um 10:00 schrieb Viechtbauer, Wolfgang (SP):
>>>> [...]
>>>> @Neal: A separate package with generic functions that pkgA and pkgB could
>> import is an interesting suggestion, thanks!
>>>
>>> What makes this interesting is that there is no dependency on other
>>> packages in generics.
>>>
>>> Remains the question which help page would be shown for help(foo).
>>
>> If a package imports and then exports the generic, it would normally
>> create a help page referring to the original one where the generic is
>> defined.  So both pkgA and pkgB would probably both create help pages,
>> and the help system would show a page listing them both plus the generic
>> one, and asking the user to choose.
>>
>> An example happens if you use
>>
>> library(broom)
>> ?tidy
>>
>> The broom package links to a page that says "These objects are imported
>>from other packages. Follow the links below to see their documentation."
>> One of the links is to the ?tidy page in the generics package.
>>
>> You are allowed to say ?broom::tidy, and then you don't go to the list
>> of possibilities, you go directly to the one you asked for.
>>
>> Duncan Murdoch