[Bioc-devel] Nasty function collision

Martin Maechler maechler at stat.math.ethz.ch
Wed Nov 1 09:57:01 CET 2006

>>>>> "JimMcD" == James W MacDonald <jmacdon at med.umich.edu>
>>>>>     on Tue, 31 Oct 2006 16:30:28 -0500 writes:

    JimMcD> Seth Falcon wrote:
    >> Code that does the optional generic definition really needs to go away
    >> at this point (I know it was needed at some point, so I'm not trying
    >> to point a finger or anything).  To be specific, I'm referring to any
    >> code that does something along the lines of:
    >> if (!isGeneric("foo"))
    >> setGeneric("foo") ...

Hmm, am I understanding correctly?
This is "bad" because it can destroy consistent behavior in the
case when there's already a non-S4 function foo() present?
Whereas  when not doing setGeneric(), the non-S4 function foo() will become
the default method as soon as the first setMethod("foo", ....)
But if that's true, it seems to me, setGeneric() should never be
used anymore, and I somehow doubt that..

Maybe this part of the discussion should really be done on
R-devel rather than bioc-devel.

    JimMcD> I tried removing the if(!isGeneric("foo")) lines from annaffy and 
    JimMcD> re-installed, and it didn't make a difference. However, re-setting the 
    JimMcD> method as Colin suggested:

    JimMcD> setMethod("getURL", "ANY", function(object) {
    JimMcD> RCurl::getURL(object)
    JimMcD> })

    JimMcD> did work, do it appears to me that the real cause of the collision is 
    JimMcD> this particular method rather than co-opting an existing generic.

Thanks, gentlemen, for the interesting discussion, to which I'm
chiming in late.

I tend to agree with Jim here that I think it's a pretty
``impolite'' inter-package-citizenship behavior to ever define

  setMethod("SomeGeneric", "ANY", function(......) ......)

because you do trash other method definitions for
"SomeGeneric" at your package load time.

I'd say a good R-izen has at least one of his/her own classes in
every signature (s)he defines methods for.

Martin Maechler, ETH Zurich

More information about the Bioc-devel mailing list