I'm not really sure how verboten it is to have methods that omit "...". The
code seems to be instrumented to handle that case.
The catch is that it does so by inserting a call to .local where .local is the
method function, e.g. if you insert a browser() call at the start of the
method, you'll see
> foo("a")
Called from: .local(x, y, ...)
Browse[1]> sys.status()
$sys.calls
$sys.calls[[1]]
foo("a")
$sys.calls[[2]]
foo("a")
$sys.calls[[3]]
.local(x, y, ...)
$sys.calls[[4]]
browser()
and the 3rd call is absent for foo(0). But y is not missing in the .local call,
because, hey, it has a default in the parent.
This also happens in plain function calls, e.g.
> f <- function(a=0)(function(a)missing(a))(a)
> f()
[1] FALSE
Also notice that it is not really "..." that is the trigger of this effect, but
the fact that the method has different arguments from the generic in any way:
You get the same situation with
> setMethod("foo", signature="numeric", function(x, y=0, z=1, ...){
+ if (missing(y))
+ return("must give y for numeric")
+ y
+ })
> foo(0)
[1] 0
-pd
> On 18 Apr 2024, at 06:32 , Jeff Newmiller via R-help <r-help@r-project.org>
> wrote:
>
> Fascinating. Or, well, not.
>
> Failing to use a method signature that is compatible with the generic is a
> no-no. So your bug seems to me to be outside the bounds of how R is supposed
> to be used. So don't do that.
>
> On April 17, 2024 4:25:38 PM PDT, "Boylan, Ross via R-help"
> <r-help@r-project.org> wrote:
>> When a generic (S4) has an argument with a default followed by ...,
>> missing() doesn't seem to work if the method omits the ...
>> --------------------Sample-------------------------------
>> foo <- function(x, y=0, ...){
>> "you are very generic"
>> }
>>
>> # no ... in function arguments
>> setMethod("foo", signature="character", function(x, y=0){
>> if (missing(y))
>> return("must give y for character")
>> y
>> })
>>
>> setMethod("foo", signature="numeric", function(x, y=0, ...){
>> if (missing(y))
>> return("must give y for numeric")
>> y
>> })
>>
>> print(foo("a")) #[1] 0
>> print(foo(0)) #[1] "must give y for numeric"
>> ------------------------------------------------------------------
>> It's the result for foo("a") I'm puzzled by, since missing(y) does not
>> evaluate to TRUE.
>>
>> Background
>> ==========
>> The methods documentation has 2 points on which the above definitions may
>> fail.
>>
>> 1. The generic has regular arguments and ... arguments. But dotsMethods
>> docs say
>>> either the signature of the generic function is "..." only, or it
>>> does not contain "..."
>> Since the arguments in ... are not part of the signatures I think I'm OK,
>> but another reading is that
>> one just shouldn't mix ... and other arguments.
>>
>> 2. setMethod docs say
>>> The definition must be a function with the same formal arguments as the
>>> generic; however, setMethod() will handle methods that add arguments, if
>>> ... is a formal argument to the generic.
>> Since the initial definition has arguments x, y, ... and the first method
>> definition has only x, y, the arguments don't match. So maybe that's the
>> problem.
>>
>> I don't know if the fact that y has a default value matters.
>>
>> The real code has a function f that ordinarily requires an additional piece
>> of information, y, to compute a result. But for one class, the result
>> doesn't depend on y and so that argument may be omitted.
>>
>> Context
>> ======
>> R 4.3.3 on MS-Windows under RStudio 2023.12.1 build 402.
>>
>> Thanks for any insights.
>> Ross
>>
>> ______________________________________________
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
> --
> Sent from my phone. Please excuse my brevity.
>
> ______________________________________________
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd....@cbs.dk Priv: pda...@gmail.com
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
