[Rd] promptClass misses methods

Seth Falcon sfalcon at fhcrc.org
Sat Dec 2 20:03:51 CET 2006


Ross Boylan <ross at biostat.ucsf.edu> writes:
> That answers my question.  The meaning was if "foo" is an S3 method,
> should one avoid defining "foo" as an S4 method.  And the answer is
> no, it's OK.  I assume one should strive to use the same argument
> names, although since S3 methods don't need to use the same argument
> names I'm not sure how that works (e.g. for S3
>   foo.class1 <- function(x, a, b) but
>   foo.class2 <- function(x, c)
> ). 

I believe you _must_ use the same arguments.  When calling
setMethod("foo", ...) where foo is a function, but not a
standardGeneric, the function foo becomes the default for a newly
created generic and the signature for the new generic is taken from
the formal arguments of the original function foo.  Clear as mud?

If you want to use different argument names, then you want your own
generic.  That is ok, IMO.  That is why we have name spaces.  It only
makes sense to set a method on an existing function (plain function,
S3, or S4 generic) if it "means" the same thing [this is obviously
fuzzy].  IMO, there is no benefit of sharing a generic or having a
default function on a generic that doesn't make sense.

Here's an example of creating a generic out of the head function:

    > setClass("FOO", representation(x="character"))
    [1] "FOO"
    > getGeneric("head")
    NULL
    > args(head)
    function (x, ...) 
    NULL
    > setMethod("head", "FOO", function(x, ...) x at x[1:10])
    Creating a new generic function for "head" in ".GlobalEnv"
    [1] "head"
    > getGeneric("head")
    standardGeneric for "head" defined from package "utils"
    
    function (x, ...) 
    standardGeneric("head")
    <environment: 0x1d56600>
    Methods may be defined for arguments: x 

Now head() is a good example because it means something like "show me
the first part of something".  But your application might want a
function named head that meant "what's attached to the neck of an
animal".  In that case, a new generic within your package's name space
seems advisable.

+ seth



More information about the R-devel mailing list