[Bioc-devel] Problem with generic methods name conflicts

[Kasper Daniel Hansen]

Herb,

First I want to point out that this is an excellent case related to
the recent discussion I tried to initiate about clashes of generics.

Second I will note (like you have already noticed) that this is a
recent addition to Biobase, seemingly coming from the DEseq crowd and
that this particular generic is not used at all in Biobase, it just
contains the generic.

The best solution to this is of course to agree with the other
package(s) about the signature of the generic.  You are using
  object, ...
which to me seems very nice. Biobase is using
  cds, normalized=TRUE
To me it seems that "object" works better as the function argument of
a generic, and that you are right in adding the ....  Also,
"normalized=TRUE" seems (to me) to be something that really belongs in
the individual method (is this really relevant for all signatures?),
so my suggestion would be to adapt your generic into Biobase.  It
should be easy for DEseq to change the signature in that (and possible
other?) packages.

But since I am not really involved in any of the packages, I am not
sure my opinion counts for much.

Kasper

On Thu, Oct 13, 2011 at 11:04 AM, Herb Holyst <holyst at mail.med.upenn.edu> wrote:
> Hi,
>
>        I am hoping someone can point me in the right direction. I received a courtesy message from the Marc Carlson the our  package flowFP had compilation errors, and after a bit of poking I discovered the Biobase added a new generic method called 'counts' which we had previously defined in flowFP.  Since our package depends on Biobase we have a name collision.
>
> Here is the definition of our 'counts' generic out of flowFP's AllGenerics.R file:
> ## =========================================================================
> ## counts Methods.
> ## - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> if (!isGeneric("counts")) {
>    setGeneric("counts", function(object, ...) standardGeneric("counts"))
> }
>
> setMethod("counts",
>    signature=signature(object="flowFP"),
>    definition=getFPCounts)
>
> setMethod("counts",
>    signature=signature(object="flowFPPlex"),
>    definition=function(object, ...) {
>        cnts = matrix(0, nrow=nInstances(object), ncol=0)
>        for(fp in object at fingerprints)
>            cnts = cbind(cnts, counts(fp, ...))
>        return(cnts)
>    }
> )
>
> With my limited knowledge the only solution I come up with is to change flowFP's method name from 'counts' to something else like 'nCounts'. This is unsettling, and I would think there must be a way to tell the dispatcher how to differentiate the two calls by code signature, but so far I am finding nothing that talks about this, at least in terms that I can comprehend.
>
> Can anyone suggest a possible solution or work around for this issue?
>
> Here is the output of my attempt to build flowFP with the latest version of Biobase. (Renaming the 'counts' method results in a error free build.)
>
> [devel]$ R CMD build flowFP
> [1] "en_US.iso885915"
> Thu Oct 13 10:51:56 2011
> Hello Herb!
> * checking for file 'flowFP/DESCRIPTION' ... OK
> * preparing 'flowFP':
> * checking DESCRIPTION meta-information ... OK
> * cleaning src
> * running 'cleanup'
> * installing the package to re-build vignettes
>      -----------------------------------
> [1] "en_US.iso885915"
> Thu Oct 13 10:51:57 2011
> Hello Herb!
> * installing *source* package 'flowFP' ...
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> gcc -std=gnu99 -I/usr/local/lib64/R/include  -I/usr/local/include    -fpic  -g -O2 -c flowFP.c -o flowFP.o
> gcc -std=gnu99 -I/usr/local/lib64/R/include  -I/usr/local/include    -fpic  -g -O2 -c init.c -o init.o
> gcc -std=gnu99 -I/usr/local/lib64/R/include  -I/usr/local/include    -fpic  -g -O2 -c split_utils.c -o split_utils.o
> gcc -std=gnu99 -shared -L/usr/local/lib64 -o flowFP.so flowFP.o init.o split_utils.o
> installing to /tmp/RtmpNOOuIP/Rinst594ef86a/flowFP/libs
> ** R
> ** data
> ** inst
> ** preparing package for lazy loading
> Scalable Robust Estimators with High Breakdown Point (version 1.3-01)
> Warning: replacing previous import '.__C__character' when loading 'methods'
> Error in match.call(definition, call, expand.dots) :
>  unused argument(s) (object = c("flowFP", "flowFP"))
> Error : unable to load R code in package 'flowFP'
> ERROR: lazy loading failed for package 'flowFP'
> * removing '/tmp/RtmpNOOuIP/Rinst594ef86a/flowFP'
>      -----------------------------------
> ERROR: package installation failed
>
>
> Thanks in advance,
> Herb
>
> Herb Holyst
> Path BioResearch
> University of Pennsylvania
>
>
>        [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>