[Bioc-devel] Problem with generic methods name conflicts

[Martin Morgan]

On 10/13/2011 08:04 AM, Herb Holyst 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"))
> }

I think that this construct pre-dates name spaces; it's weird (to me) to 
define a method on a generic that one doesn't know about, e.g., maybe 
'counts' is documented to return a vector of European nobleman. It also 
implies that 'counts' is found on the user search path rather than in 
the package name space, so sometimes the intended counts is found, 
sometimes not.

These days I think that one would importFrom(Biobase, counts) and then 
setMethod on the known generic (if Biobase has an appropriate counts 
generic) or create a new generic (which I think would not normally be 
the case).

A secondary question that quickly comes up is how to make the user aware 
of the generic 'counts'.

On the one hand (I think this is the usual solution) it might be 
appropriate to (in the DESCRIPTION file)

   Depends: Biobase
   Imports: Biobase

and (in the NAMESPACE file)

   importFrom(Biobase, counts)
   exportMethods(counts)

which arranges for the counts generic from Biobase to be available to 
you for attaching methods, and to the user via the standard search path, 
and for the methods defined in your package to be associated with that 
generic.

On a second hand one might think that, while your package has a use for 
some-of-Biobase, the user does not have a use for all-of-Biobase so

   Imports: Biobase

and

   importFrom(Biobase, counts)
   export(counts)

which allows you to add your methods to Biobase::counts, then passes 
Biobase::counts through to be visible to the user. This seems awkward; 
it requires that you document the 'counts' generic (you're the one 
making it available to the user) even though the generic is in Biobase. 
The motivation for not attaching Biobase to the search path is probably 
part of the motivation for a BiocGenerics class -- too much clutter for 
the user.

On the third hand one might forgo Biobase entirely (neither Depends: nor 
Imports:), define a generic counts in your own package and export that. 
Let the user disambiguate if they happen to load Biobase in addition to 
your package. For disparate data types and questions this might be 
appropriate, but for data types shared by different packages it 
unfortunately leads to a multiplication of classes and a confusion of 
interfaces.

On the fourth hand, perhaps your package has a use for some of Biobase 
but the user does not. So Imports: and importFrom, with no exports.

There are likely to be other hands.

Martin


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


-- 
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793