[R-pkg-devel] Getting two independent packages with identical S3 generics to dispatch each other's methods

Pavel N. Krivitsky p@kr|v|t@ky @end|ng |rom un@w@edu@@u
Sat Jul 11 01:51:52 CEST 2020

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

> 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(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

			Thank you in advance,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.character_1.0.tar.gz
Type: application/x-compressed-tar
Size: 545 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20200711/0320f31c/attachment.bin>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.numeric_1.0.tar.gz
Type: application/x-compressed-tar
Size: 546 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20200711/0320f31c/attachment-0001.bin>

More information about the R-package-devel mailing list