R optional arguments for S4 setMethod

Question

I am interested in setting new methods for generic functions. For example, let's say I have a new class (e.g. coolClass). I could write a wrapper to calculate the log10 of that class and easily set the method with the following code:

setMethod("Math", c(x="coolClass"),
          function(x)
          {
            op = .Generic[[1]]
            switch(op,
                   `log10` = log10_for_coolClass(x),
                   stop("Undefined operation")
            )
          }
)

However, I am unable to figure out how to set a method to pass multiple arguments. For example, the generic log method. Running getGeneric("log") shows the following:

> getGeneric("log")
standardGeneric for "log" defined from package "base"
  belonging to group(s): Math 

function (x, ...) 
standardGeneric("log", .Primitive("log"))
<bytecode: 0x2f9a958>
<environment: 0x2f937f0>
Methods may be defined for arguments: x
Use  showMethods("log")  for currently available ones.

Seeing this, I would expect I could write the following to be able to pass the optional base argument.

setMethod("Math", signature(x="coolClass",...),
          function(x, ...)
          {
            op = .Generic[[1]]
            switch(op,
                   `log` = log_for_coolClass(x, ...),
                   stop("Undefined operation")
            )
          }
)

But I get the following error:

Error in matchSignature(signature, fdef, where) : 
  '...' used in an incorrect context

Tried without ... in the signature I get a different error:

Error in rematchDefinition(definition, fdef, mnames, fnames, signature) : 
   methods can add arguments to the generic ‘Math’ only if '...' is an argument to the generic

Which seems strange to me given that getGeneric log shows the ... in the method.

Any ideas? Is there a way to capture additional arguments? I am trying to become more comfortable with S4 methods but I am confused about how to pass optional arguments. If this is not possible, I would appreciate it if someone could explain how the log function does work, for example, given that the function is part of the Math group but accepts multiple arguments.

Update

Curiously, as noted below, I can use setMethod directly on log with the following:

setMethod("log", signature(x="big.matrix"),
          function(x, base=exp(1))
            {
            log_for_coolClass(x, base=base)
          }
          )

However, this doesn't quite pacify my curiosity. For example, it seems strange to be so repetitive in code if I creating many new methods within the Math group. Ideally it would look something like this:

setMethod("Math", c(x="coolClass"),
          function(x, base=exp(1))
          {
            op = .Generic[[1]]
            switch(op,
                   `log10` = log10_for_coolClass(x),
                   `log` = log_for_coolClass(x, base=base),
                   stop("Undefined operation")
            )
          }
)

Answer 1

Here's a class

.A <- setClass("A", representation(x="numeric"))

For a function like log we have

> getGeneric("log")
standardGeneric for "log" defined from package "base"
  belonging to group(s): Math 

function (x, ...) 
standardGeneric("log", .Primitive("log"))
<bytecode: 0x2b41b28>
<environment: 0x2b39df8>
Methods may be defined for arguments: x
Use  showMethods("log")  for currently available ones.

where the signature includes .... So we write

setMethod("log", "A", function(x, ...) {
    log(x@x, ...)
})

and have success

> log(.A(x=c(1, 2, NA)))
[1] 0.0000000 0.6931472        NA
> log(.A(x=c(1, 2, NA)), base=2)
[1]  0  1 NA

Next up: log10

> getGeneric("log10")
standardGeneric for "log10" defined from package "base"
  belonging to group(s): Math 

function (x) 
standardGeneric("log10", .Primitive("log10"))
<bytecode: 0x2b4a700>
<environment: 0x2b43138>
Methods may be defined for arguments: x
Use  showMethods("log10")  for currently available ones.

No ... arguments in the generic, so we're basically stuck -- write our own generic and implement methods that do include ..., or write a log10,A-method that does not have ... argument.

The same principle with respect to ... applies to group generics -- the Math group generic doesn't have dots

> getGeneric("Math")
groupGenericFunction for "Math" defined from package "base"

function (x) 
standardGeneric("Math")
<bytecode: 0x2771d40>
<environment: 0x275ee20>
Methods may be defined for arguments: x
Use  showMethods("Math")  for currently available ones.

so our method (implementing all Math operations, not just log; note that we don't typically reference .Generic explicitly) on objects of our class might be

setMethod("Math", "A", function(x) {
    callGeneric(x@x)
})

and now we have methods for all the Math functions, e.g.,

> sqrt(.A(x=1:4))
[1] 1.000000 1.414214 1.732051 2.000000

also, our variant of log, accepting ..., is still available, so we can both define behavior of our class for all Math generics, and provide specialized implementations for specific generics.

There is probably a bug in the implementation of these group generics that should be addressed. If in a new session we defined our class and Math generic, but not the log function with ... argument, we can still invoke

> log(.A(x=1:4))
[1] 0.0000000 0.6931472 1.0986123 1.3862944
> log(.A(x=1:4), base=2)
[1] 0.0000000 0.6931472 1.0986123 1.3862944

where the second argument is ignored but should really cause an error.