[Bioc-devel] Problem with generic methods name conflicts

Vincent Carey stvjc at channing.harvard.edu
Thu Oct 13 17:29:33 CEST 2011


On Thu, Oct 13, 2011 at 11:14 AM, Kasper Daniel Hansen
<kasperdanielhansen at gmail.com> wrote:
> 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,

I agree with this comment about parameter names in generics.

> "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.

I would hope that this could happen, and that some review of generic
programming and
policies could be taken up in Manchester.

>
> 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
>>
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



More information about the Bioc-devel mailing list