A set of distinct inherited signatures is generated to test inheritance for all the methods of a specified generic function. If method selection is ambiguous for some of these, a summary of the ambiguities is attached to the returned object. This test should be performed by package authors before releasing a package.
testInheritedMethods(f, signatures, test = TRUE, virtual = FALSE, groupMethods = TRUE, where = .GlobalEnv)
a generic function or the character string name of one. By default, all currently defined subclasses of all the method signatures for this generic will be examined. The other arguments are mainly options to modify which inheritance patterns will be examined.
An optional set of subclass signatures to use instead of the relevant
subclasses computed by
optional flag to control whether method selection is actually tested.
should virtual classes be included in the relevant subclasses. Normally not, since only the classes of actual arguments will trigger the inheritance calculation in a call to the generic function. Including virtual classes may be useful if the class has no current non-virtual subclasses but you anticipate your users may define such classes in the future.
should methods for the group generic function be included?
the environment in which to look for class definitions. Nearly always, use the default global environment after attaching all the packages with relevant methods and/or class definitions.
The following description applies when the optional arguments are
omitted, the usual case.
First, the defining signatures for all methods are computed by calls
From these all the known non-virtual subclasses are found for each
class that appears in the signature of some method.
These subclasses are split into groups according to which class they
inherit from, and only one subclass from each group is retained (for
each argument in the generic signature).
So if a method was defined with class
"vector" for some
argument, one actual vector class is chosen arbitrarily.
The case of
"ANY" is dealt with specially, since all classes
extend it. A dummy, nonvirtual class,
".Other", is used to
correspond to all classes that have no superclasses among those being
All combinations of retained subclasses for the
arguments in the generic signature are then computed.
Each row of the resulting matrix is a signature to be tested by a call
To collect information on ambiguous selections,
testInheritedMethods establishes a calling handler for the
"ambiguousMethodSelection", by setting the
An object of class
"methodSelectionReport". The details of
this class are currently subject to change. It has slots
"note", all referring to the ambiguous cases (and so of length
0 if there were none). These slots are intended to be examined by the
programmer to detect and preferably fix ambiguous method selections.
The object contains in addition slots
"generic", the name of
the generic function, and
"allSelections", giving the vector of labels for all
the signatures tested.
Chambers, John M. (2008) Software for Data Analysis: Programming with R Springer. (Section 10.6 for basics of method selection.)
Chambers, John M. (2009) Class Inheritance in R https://statweb.stanford.edu/~jmc4/classInheritance.pdf.
## if no other attached packages have methods for `+` or its group ## generic functions, this returns a 16 by 2 matrix of selection ## patterns (in R 2.9.0) testInheritedMethods("+")
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.