[Bioc-devel] Candidates for BiocGenerics

Nicolas Delhomme delhomme at embl.de
Thu Mar 1 21:21:32 CET 2012 

On 1 Mar 2012, at 21:11, Hervé Pagès wrote:

> Hi Nico,
> 
> On 03/01/2012 11:05 AM, Nicolas Delhomme wrote:
>> 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)
>>             }
>>           })
> 
> So your RNAseq class seems to be some kind of union between the
> Genome_intervals_stranded class defined in the genomeIntervals
> package and some other class(es) defined in the GenomicRanges
> package?
> 

Kind of; it's not really an union, but I do use both of some of their functionalities.

> There are so many differences in the way genomeIntervals and
> GenomicRanges deal with ranges that implementing things that
> work on top of both must lead to all kind of headaches indeed ;-)
> Like for example here, your "strand" method for RNAseq objects
> will sometimes return a factor with 2 levels (-, +) and sometimes
> a factor-Rle with 3 levels (+, -, *).
> 

You name it ;-)

> Anyway, yes it seems to make sense to move the strand() generic to
> BiocGenerics so I will to that.

Great! I'll see with Julien if he can adapt to that.

> 
>> 
>> 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?
> 
> Mmmh, I guess reduce() is one of those situations where having
> the BiocGenerics package doesn't help much. intervals being on
> CRAN, it would not make a lot of sense to ask them to depend on
> BiocGenerics. And I don't like the idea of having IRanges depending
> on intervals either for the only purpose of importing their generic
> (and in any case they would first need to change its signature which
> is not "setMethod-friendly" at the moment).
> 
Exactly. I knew it was kind of a dead-lock here. I was just curious to know if there would be a possibility to link these two "worlds".

Anyway, I'll see with the authors of this package if at least sharing the same signature is something do-able.

Cheers,

Nico


> Cheers,
> H.
> 
>> 
>> 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
>> 
> 
> 
> -- 
> 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

More information about the Bioc-devel mailing list