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-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Tuesday, 23 June, 2020 12:25
To: Guido Schwarzer; r-package-devel@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
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
