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 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#workaroundEven 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. Tomas>> Tomas >> >> > I?aki
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
On 02/22/2018 02:31 PM, I?aki ?car wrote:> 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?Yes, it will also result in runtime error after the change is committed: calling c.foo... Error in NextMethod("c") : 'NextMethod' called from an anonymous function>>>> 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.There may be a more elegant way, but that'd be a question for R-help and it might be worth giving a broader context for what you want to achieve. Also please note that S3 dispatch is done on the first argument, and c() gives no special meaning to its first argument, what if e.g. the second argument is of class "foo" but the first is not - is S3/NextMethod really a good fit here? Tomas> >> Tomas >> > I?aki