Dear developers,
I maintain a package, emmeans, that provides post-hoc analyses for a variety of
models. These models are supported by writing S3 methods for recover_data and
emm_grid. Quite a few models are supported internally in emmeans, but it would
really be better if the packages that cre
On Sat, 10 Aug 2019 at 19:21, Lenth, Russell V wrote:
>
> Dear developers,
>
> I maintain a package, emmeans, that provides post-hoc analyses for a variety
> of models. These models are supported by writing S3 methods for recover_data
> and emm_grid. Quite a few models are supported internally i
Thanks Iñaki,
However...
> 1) renaming those methods (e.g., recover_data_foo, because as soon as
there is a something.foo
> in your namespace, it will be dispatched regardless of whether you
register it or not)
If I do that, then emmeans won't support foo objects until foopkg offers
H, I thought of an approach -- a kind of manual dispatch technique. My
generic is
recover_data <- function(object, ...) {
rd <- try(getS3method("recover_data", class(object)[1], envir = .GlobalEnv,
silent = TRUE))
if (!inherits(rd, "try-error"))
rd(object, ...)
else
Thanks, Neonira. Always something new to learn!
Russ
From: neonira Arinoem
Sent: Saturday, August 10, 2019 2:22 PM
To: Lenth, Russell V
Cc: Iñaki Ucar ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: Farming out methods to other packages
What about turning your S3 clas
On 10/08/2019 3:27 p.m., Lenth, Russell V wrote:
H, I thought of an approach -- a kind of manual dispatch technique. My
generic is
recover_data <- function(object, ...) {
rd <- try(getS3method("recover_data", class(object)[1], envir =
.GlobalEnv, silent = TRUE))
if (!inherits(rd,
Thanks, Duncan. That's helpful.
In addition, I confess I had a closing parenthesis in the wrong place.
Should be:. . . .GlobalEnv), silent = TRUE)
Cheers,
Russ
-Original Message-
From: Duncan Murdoch
Sent: Saturday, August 10, 2019 2:43 PM
To: Lenth, Russell V ; Iñaki Ucar
You could have your default method handle the cases you can handle; if
you want that to dispatch you can use something like
recover_data.default <- function(object, ...)
default_recover_data(object, ...)
default_recover_data <- function(object, ...)
UseMethod("default_recover_data")
Bes
Thanks, Luke.
That's more efficient for sure. I'd just have to rename about a zillion
existing internal methods -- but only once!
Additional advantage I see is ability to control WHICH methods I'd allow to be
overridden.
Russ
-Original Message-
From: Tierney, Luke
Sent: Saturday, A
On Sat, 10 Aug 2019 at 21:11, Lenth, Russell V wrote:
>
> Thanks Iñaki,
>
> However...
>
> > 1) renaming those methods (e.g., recover_data_foo, because as soon as
> there is a something.foo
> > in your namespace, it will be dispatched regardless of whether you
> register it or not)
>
> I
On Sat, 10 Aug 2019 at 22:14, Tierney, Luke wrote:
>
> You could have your default method handle the cases you can handle; if
> you want that to dispatch you can use something like
>
> recover_data.default <- function(object, ...)
> default_recover_data(object, ...)
> default_recover_data <-
All,
I'm going with the previous approach, as modified by Duncan, primarily because
I want to keep recover_data.lm and a few others.
So if I fit a model 'm3' using stanreg::rstanarm:
class(m3)
[1] "stanreg" "glm" "lm" "lmerMod"
Using the setup that Luke suggests, I have a def
12 matches
Mail list logo
