2018-02-22 12:39 GMT+01:00 Tomas Kalibera <tomas.kalib...@gmail.com>:
> On 02/22/2018 12:07 PM, Iñaki Úcar wrote:
>> 2018-02-22 10:29 GMT+01:00 Tomas Kalibera <tomas.kalib...@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
    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


R-devel@r-project.org mailing list

Reply via email to