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

Jeff Newmiller jdnewm|| @end|ng |rom dcn@d@v|@@c@@u@
Sat Jul 11 02:15:38 CEST 2020



On July 10, 2020 4:51:52 PM PDT, "Pavel N. Krivitsky" <p.krivitsky using 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
>> 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
>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
>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,
>			Pavel

Sent from my phone. Please excuse my brevity.

More information about the R-package-devel mailing list