Yet another alternative is simply to prevent your second package from overriding the previously defined generic. The basic problem is the ease with which R allows overriding prior generic definitions (one of those bits of bad behavior we in the USA used to call "a Bozo No-No"), which hides all the previous methods, as demonstrated by the following code:
> plot(1:3) > > plot <- function(x, ...) UseMethod("plot") > > plot(1:3) > Error in UseMethod("plot") : > no applicable method for 'plot' applied to an object of class > "c('integer', 'numeric')" > > rm(plot) > > plot(1:3) (Despite Murdoch's suggestion that overriding the generic SHOULD issue a warning, it doesn't seem to in R 4.0.1.) So, we might try protecting the generic definitions of "foo" in both packages by enclosing them in something like: tryCatch(invisible(methods("foo")), error = {foo <- function(x,...) > UseMethod("foo")}, finally=NULL) There's probably a more elegant way to accomplish this. This relies on "methods" returning an error if "foo" has no defined methods, so it is not redefined if their are previous methods. I haven't had time to try this in the two-package example, but it might work, although I'm not sure how to handle the Namespace declarations. Tom Wainwright On Mon, Jun 22, 2020 at 10:41 AM Bert Gunter <bgunter.4...@gmail.com> wrote: > ... > and just to add to the query, assume the author of pkg B did (does) not > know of pkg A and so, for example, could (did) not import any of pkg A's > content into B. Given that there are at the moment ~20,000 packages out > there, this does not seem to be an unreasonable assumption. One may even > further assume that the user may not know that (s)he has package B loaded, > as it may be a dependency of another package that (s)he uses. I certainly > don't keep track of all the dependencies of packages I use. > > Under these assumptions, is there any more convenient alternative to > Wolfgang's pkgA:foo(x) explicit call under such assumptions? If pkgA has a > long name, what might one do? > > Bert Gunter > > "The trouble with having an open mind is that people keep coming along and > sticking things into it." > -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) > > > On Mon, Jun 22, 2020 at 10:00 AM Viechtbauer, Wolfgang (SP) < > wolfgang.viechtba...@maastrichtuniversity.nl> wrote: > > > Hi All, > > > > Let's say there are two packages pkgA and pkgB, both of which have a > > generic function > > > > foo <- function(x, ...) > > UseMethod("foo") > > > > and pkgA has a method for objects of class "A": > > > > foo.A <- function(x, ...) > > print(x) > > > > and pkgB has a method for objects of class "B": > > > > foo.B <- function(x, ...) > > plot(x) > > > > Both packages export foo and their method and declare their respective S3 > > methods, so: > > > > export(foo) > > export(foo.A) > > S3method(foo, A) > > > > in NAMESPACE of pkgA and > > > > export(foo) > > export(foo.B) > > S3method(foo, B) > > > > in NAMESPACE of pkgB. > > > > If a user loads pkgA first and then pkgB, this fails: > > > > library(pkgA) > > library(pkgB) > > x <- 1:4 > > class(x) <- "A" > > foo(x) > > > > Error in UseMethod("foo") : > > no applicable method for 'foo' applied to an object of class "A" > > > > and vice-versa. Of course, pkgA::foo(x) works. Aside from pkgA importing > > foo() or vice-versa, is there some other clever way to make this work? In > > earlier versions of R (at least in 3.6.3), this used to work (i.e., the > > generic foo() from pkgB would find method foo.A() and vice-versa), but > not > > since 4.0.0. > > > > Best, > > Wolfgang > > > > ______________________________________________ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel