Dear Duncan et al.,
Firstly, my apologies for the duplicated query. It seems that I had
searched everywhere but the mailing list where I asked the question.
Secondly, I was wondering if I could get some indication whether CRAN
would accept a package with the following code and documentation (and
only that):
1) A number of exported generics of the form
summary_formula(object, ..., lhs),
simulate_formula(object, nsim=1, seed=NULL, ..., lhs),
etc.,
which expect a formula as their first argument, evaluate the LHS of the
formula, and dispatch based on the class of the result, which can also
be overridden by the lhs= argument.
2) Corresponding S3 methods summary.formula(), simulate.formula(), etc.
methods, that call the corresponding *_formula() generic.
I am familiar with the generics package, but I don't think it's a good
place for this functionality, because this is not the typical
dispatching behaviour, and because *.formula() exports are not
technically generics but S3 methods. In particular, as far as I know,
existing mechanisms make it easy to cherry-pick generics, but they
don't make it easy to cherry-pick methods.
Best Regards,
Pavel
On Sat, 2020-07-11 at 07:29 -0400, Duncan Murdoch wrote:
> 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.
>
> Duncan Murdoch
>
> 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
> > 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
> >
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
