[R-pkg-devel] Getting two independent packages with identical S3 generics to dispatch each other's methods
Hi Pavel, I asked essentially the same question a few weeks ago: https://stat.ethz.ch/pipermail/r-package-devel/2020q2/005609.html As Jeff already suggested, there is the generics package which might be of use. Aside from this, I wasn't able to distill a workable solution from the discussion that did not involve adding dependencies to (one of) the two packages. Best, Wolfgang
On July 11, 2020 1:51:52 AM GMT+02:00, "Pavel N. Krivitsky" <p.krivitsky at unsw.edu.au> wrote:
Dear All, I would like to have two packages that do not depend on each other that have an identical generic to be able to dispatch to each other's (non- conflicting) methods. If it is of interest, the background for why this is needed is given at the end of this e-mail. As it is, it looks like two packages that do not depend on each other both define a generic, they do not see each other's S3 methods. For example, in the two attached minimal packages, which define and export generic foo() (identical in both packages) and methods foo.character() and foo.numeric() that are exported via S3method(), we get,
library(test.character)
foo("a")
foo.character() called.
library(test.numeric)
Attaching package: ?test.numeric? The following object is masked from ?package:test.character?: foo
foo(1)
foo.numeric() called.
foo("a")
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class
"character"
That is, test.numeric::foo() doesn't "see"
test.character:::foo.character() and vice versa. Is there a way to make
them see each other?
This issue has arisen before, e.g. at
https://stackoverflow.com/questions/25251136/how-to-conditionally-define-a-generic-function-in-r-namespace
.
The "clean" solution is, of course, to create a third package to define
the generic that the two packages could import (and, if necessary,
reexport). However, that involves creating an almost-empty package that
then has to be submitted to CRAN, maintained, and add some amount of
storage and computational overhead. Is there another way to do this
that is transparent to the end user?
# Background
This arose as a result of two packages (lme4 and ergm) both wanting to
implement a simulate.formula() method, causing conflicts when the user
wanted to use both at the same time.
ergm has a mechanism for dispatching based on the class of the LHS of
the formula. It does so by defining a generic, simulate_formula() which
evaluates the formula's LHS and dispatches a method (e.g.,
simulate_formula.<CLASS>()) based on that.
Since lme4 and ergm generally use different LHSs, we are thinking of
resolving the conflict by copying the LHS dispatching mechanism from
ergm to lme4, and then defining our own summary_formula methods as
needed.
Thank you in advance,
Pavel