From i.ucar86 at gmail.com  Thu Feb 22 14:31:53 2018
From: i.ucar86 at gmail.com (=?UTF-8?B?ScOxYWtpIMOaY2Fy?=)
Date: Thu, 22 Feb 2018 14:31:53 +0100
Subject: [Rd] How to modify dots and dispatch NextMethod
In-Reply-To: <e65eec07-9e6d-4cbb-5337-bd559b6cde03@gmail.com>
References: <CALEXWq2tL2qxLee_1MhRQcqmeUXe5BfnxCjZQM5RTkB7ccD7PA@mail.gmail.com>
 <CALEXWq1eSvjMxjsu9D+he3FYrpJhyMv9mhmWzVeyk7g8bbB5EQ@mail.gmail.com>
 <8217f2fc-b660-c8bc-406d-22a1d8c4602a@gmail.com>
 <CALEXWq1=VDs2BQ2CEMJKwrtmZNCG1Scf2EfgGn91xTdH9ibGVA@mail.gmail.com>
 <e65eec07-9e6d-4cbb-5337-bd559b6cde03@gmail.com>
Message-ID: <CALEXWq2K738k8C3eDJBPdtPpixW3rr+NpssSnx+7dM2VnkOo_Q@mail.gmail.com>

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



[Rd] How to modify dots and dispatch NextMethod
=?UTF-8?B?ScOxYWtpIMOaY2Fy?=