Could somebody post this to the Bioconductor package developer guidelines?
 It seems apropos.

Like say to
http://www.bioconductor.org/developers/package-guidelines/#classes

Perhaps some 'lint'-type messages that complain "you are doing this the
wrong way"  could end up in R CMD check?



On Thu, Oct 13, 2011 at 9:52 AM, Martin Morgan <mtmorgan@fhcrc.org> wrote:

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



-- 
If people do not believe that mathematics is simple,
it is only because they do not realize how complicated life is. John von
Neumann<http://www-groups.dcs.st-and.ac.uk/~history/Biographies/Von_Neumann.html>

	[[alternative HTML version deleted]]

