Last chance! 50% off unlimited learning
Sale ends in
... in Method SignaturessetMethod. The method
definition must be written expecting all the arguments corresponding
to “...” to be from the class specified in the method's signature,
or from a class that extends that class (i.e., a subclass of that
class). Typically the methods will pass “...” down to another function or
will create a list of the arguments and iterate over that. See the
examples below. When you have a computation that is suitable for more than one existing
class, a convenient approach may be to define a union of these
classes by a call to setClassUnion. See the example
below. setMethod. If all the actual arguments
corresponding to “...” have this class, the corresponding method is
selected directly. Otherwise, the class of each argument and that class' superclasses are
computed, beginning with the first “...” argument. For the first
argument, eligible methods are those for any of the classes. For
each succeeding argument that introduces a class not considered previously, the eligible methods are further
restricted to those matching the argument's class or
superclasses. If no further eligible classes exist, the iteration
breaks out and the default method, if any, is selected. At the end of the iteration, one or more methods may be eligible.
If more than one, the selection looks for the method with the least
distance to the actual arguments. For each argument, any inherited
method corresponds to a distance, available from the contains
slot of the class definition. Since the same class can arise for
more than one argument, there may be several distances associated
with it. Combining them is inevitably arbitrary: the current
computation uses the minimum distance. Thus, for example, if a
method matched one argument directly, one as first generation
superclass and another as a second generation superclass, the
distances are 0, 1 and 2. The current selection computation would
use distance 0 for this
method. In particular, this selection criterion tends to use a method that
matches exactly one or more of the arguments' class. As with ordinary method selection, there may be multiple methods
with the same distance. A warning message is issued and one of the
methods is chosen (the first encountered, which in this case is
rather arbitrary). Notice that, while the computation examines all arguments, the
essential cost of dispatch goes up with the number of
distinct classes among the arguments, likely to be much
smaller than the number of arguments when the latter is large. setGeneric is inserted in the generic function's
environment. The local version selects a method according to the
criteria above and calls that method, from the environment of the
generic function. This is slightly different from the action taken
by the C implementation when “...” is not involved. Aside from the
extra computing time required, the method is evaluated in a true
function call, as opposed to the special context constructed by the
C version (which cannot be exactly replicated in R code.) However,
situations in which different computational results would
be obtained have not been encountered so far, and seem very
unlikely. Methods dispatching on arguments other than “...” are cached by storing
the inherited method in the table of all methods, where it will be
found on the next selection with the same combination of classes
in the actual arguments (but not used for inheritance searches).
Methods based on “...” are also cached, but not found quite
as immediately. As noted, the selected method depends only on the
set of classes that occur in the “...” arguments. Each of
these classes can appear one or more times, so many combinations of
actual argument classes will give rise to the same effective
signature. The selection computation first computes and sorts the
distinct classes encountered. This gives a label that will be
cached in the table of all methods, avoiding any further search for
inherited classes after the first occurrence. A call to
showMethods will expose such inherited methods. The intention is that the “...” features will be added to the
standard C code when enough experience with them has been obtained.
It is possible that at the same time, combinations of “...” with
other arguments in signatures may be supported.Chambers, John M. (1998) Programming with Data Springer (For the original S4 version.)
cc <- function(...)c(...)
setGeneric("cc")
setMethod("cc", "character", function(...)paste(...))
setClassUnion("Number", c("numeric", "complex"))
setMethod("cc", "Number", function(...) sum(...))
setClass("cdate", contains = "character", representation(date = "Date"))
setClass("vdate", contains = "vector", representation(date = "Date"))
cd1 <- new("cdate", "abcdef", date = Sys.Date())
cd2 <- new("vdate", "abcdef", date = Sys.Date())
stopifnot(identical(cc(letters, character(), cd1),
paste(letters, character(), cd1))) # the "character" method
stopifnot(identical(cc(letters, character(), cd2),
c(letters, character(), cd2)))
# the default, because "vdate" doesn't extend "character"
stopifnot(identical(cc(1:10, 1+1i), sum(1:10, 1+1i))) # the "Number" method
stopifnot(identical(cc(1:10, 1+1i, TRUE), c(1:10, 1+1i, TRUE))) # the default
stopifnot(identical(cc(), c())) # no arguments implies the default method
setGeneric("numMax", function(...)standardGeneric("numMax"))
setMethod("numMax", "numeric", function(...)max(...))
# won't work for complex data
setMethod("numMax", "Number", function(...) paste(...))
# should not be selected w/o complex args
stopifnot(identical(numMax(1:10, pi, 1+1i), paste(1:10, pi, 1+1i)))
stopifnot(identical(numMax(1:10, pi, 1), max(1:10, pi, 1)))
try(numMax(1:10, pi, TRUE)) # should be an error: no default method
## A generic version of paste(), dispatching on the "..." argument:
setGeneric("paste", signature = "...")
setMethod("paste", "Number", function(..., sep, collapse) c(...))
stopifnot(identical(paste(1:10, pi, 1), c(1:10, pi, 1)))
Run the code above in your browser using DataLab