How to modify dots and dispatch NextMethod
2018-02-22 12:39 GMT+01:00 Tomas Kalibera <tomas.kalibera at gmail.com>:
On 02/22/2018 12:07 PM, I?aki ?car wrote:
2018-02-22 10:29 GMT+01:00 Tomas Kalibera <tomas.kalibera at gmail.com>:
The example is invoking NextMethod via an anonymous function, which is not allowed (see documentation for NextMethod).
Thanks for your response. I definitely missed that bit.
Normally one gets a runtime error "'NextMethod' called from an anonymous function", but not here as the anonymous function is called via do.call. I will fix so that there is a runtime error in this case as well, thanks for uncovering this problem.
Then I did well chosing this list! Please also note that you could take that anonymous function out of the method and name it, and the behaviour would be the same. So maybe this case should issue an error too.
I am not sure I understand how, but if you find a way to bypass the new check for an anonymous function (I intend to commit tomorrow), I will be happy to have a look if you provide a reproducible example.
I meant with a named function inside do.call, instead of an anonymous
one. For example:
c.foo <- function(..., recursive=FALSE) {
message("calling c.foo...")
dots <- list(...)
# inspect and modify dots; for example:
if (length(dots > 1))
dots[[2]] <- 2
do.call(
c.foo.proxy,
c(dots, recursive=recursive)
)
}
c.foo.proxy <- function(..., recursive=FALSE)
structure(NextMethod("c"), class="foo")
Right now, the effect of the code above is the same as with the
anonymous function. Shouldn't it issue a similar error then?
I don't think there is a way to replace (unnamed) arguments in dots for NextMethod.
That's a pity. IMHO, it should be some mechanism for that, but dots are special in inscrutable ways. Anyway, for anyone insterested, I found a workaround: https://github.com/Enchufa2/dispatchS3dots#workaround
Even though technically this won't be too hard, I don't think NextMethod should be made any more complex than it is now. There should always be a way to implement special dispatch scenarios in R and your workaround shows it is possible specifically in your scenario.
My only concern about this workaround is that it triggers the dispatch stack again from the beginning of the class hierarchy, which seems not very elegant nor efficient.
Tomas
I?aki