[Bioc-devel] Candidates for BiocGenerics

[Nicolas Delhomme]

Hi Hervé,

I have something related to that. My package depends among others on two bioC packages: genomeIntervals and GenomicRanges that both define identical functions: strand, strand<-, reduce. 

Therefore in my own code, I need to do the dispatching myself, so I have something along those lines for these three functions

setMethod(
          f="strand",
          signature="RNAseq",
          definition=function(x){
            if(extends(class(x),"Genome_intervals_stranded")){
              genomeIntervals::strand(x)
            } else {
              GenomicRanges::strand(x)
            }
          })

For the strand and strand<- function, having the generic in BiocGenerics  would be perfect. But for the reduce one, it's more complicated since genomeIntervals inherit it from intervals, which is a CRAN package, so I suppose I would still have to do the dispatching myself for that one, which is sub-optimal for code stability. Would there be another solution? I suppose, having bioC and the maintainer of that package agree on a generic would do, but how realistic is that?

Cheers,

Nico

---------------------------------------------------------------
Nicolas Delhomme

Genome Biology Computational Support

European Molecular Biology Laboratory

Tel: +49 6221 387 8310
Email: nicolas.delhomme at embl.de
Meyerhofstrasse 1 - Postfach 10.2209
69102 Heidelberg, Germany
---------------------------------------------------------------





On 1 Mar 2012, at 19:47, Hervé Pagès wrote:

> Hi Kevin,
> 
> On 03/01/2012 10:13 AM, Kevin R. Coombes wrote:
>> I think that everything that is already an S3 generic in R should be
>> (automatically) upgraded to an S4 generic. (Four out of five of
>> Benilton's suggestions already qualify by that criterion. And ncol
>> should clearly be promoted to a generic for Bioc usage.) And a
>> suggestion by even one person who is using any base R function as a
>> generic should easily be enough to get it included in BiocGenerics.
>> 
>> I think the only question is whether there should be a core place (like
>> BiocGenerics) to contain the definitions of generics that don't
>> replace/extend functions in base R. For example, I could imagine more
>> than one person wanting a "process" generic to handle some processing
>> step for some high-throughput platforms. Is there any procedure for
>> dealing with things like this?
> 
> No formal procedure but it could also be placed in BiocGenerics.
> 
> We already have things there (combine, updateObject) that don't
> replace/extend functions in base R (see ?BiocGenerics).
> 
> I also have on my list to move all the generics for count datasets
> currently defined in Biobase (and used by the DESeq and DEXSeq
> packages) to BiocGenerics.
> 
> The criteria for such a move is not as clear as for the stuff that
> is already in base R though. What we want to avoid is having the same
> generic defined twice so if 2 packages want to define a "process"
> generic then one should depend on the other one so the second one
> does not need to redefine the generic, it just needs to define methods
> on it. If, for whatever reason, having one package depend on the
> other is not desirable, then the generic should go in BiocGenerics.
> 
> Cheers,
> H.
> 
> 
>> Kevin
>> 
>> On 3/1/2012 10:18 AM, Sean Davis wrote:
>>> On Thu, Mar 1, 2012 at 7:57 AM, Benilton Carvalho
>>> <beniltoncarvalho at gmail.com> wrote:
>>>> Hi,
>>>> 
>>>> I'm implementing a few things in oligo and I wonder if it'd make
>>>> sense to have
>>>> 
>>>> boxplot/coef/image/ncol/residuals
>>>> 
>>>> defined in BiocGenerics?
>>>> 
>>>> If it's only me using them, I'm happy to have everything in oligo.
>>>> 
>>>> Thoughts?
>>> It seems that if someone is proposing a generic for functionality
>>> already in base R, that generic is by definition a good candidate for
>>> inclusion in BiocGenerics. Are there downsides to having this be a
>>> criterion for inclusion?
>>> 
>>> Sean
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> -- 
> Hervé Pagès
> 
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
> 
> E-mail: hpages at fhcrc.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319
> 
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel