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.krivit...@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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel