[R-pkg-devel] Getting two independent packages with identical S3 generics to dispatch each other's methods
murdoch@dunc@n @end|ng |rom gm@||@com
Sat Jul 11 13:29:00 CEST 2020
If the semantics of the two generics must remain identical in the
future, then there is an implicit dependency between the code in the
packages. You should formalize this by using one of the dependency
mechanisms that the language provides, i.e. the clean solution.
On 10/07/2020 7:51 p.m., Pavel N. Krivitsky 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
> foo.character() called.
> Attaching package: ‘test.numeric’
> The following object is masked from ‘package:test.character’:
> foo.numeric() called.
> 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,
> R-package-devel using r-project.org mailing list
More information about the R-package-devel