[Bioc-devel] Candidates for BiocGenerics

Hervé Pagès hpages at fhcrc.org
Fri Mar 2 11:30:43 CET 2012 

On 03/01/2012 12:21 PM, Nicolas Delhomme wrote:
>
> 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.

Done in BiocGenerics 0.1.10

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

Even better, I suggest you bring this case on R-devel to get reduce
added to stats4 ;-)

Cheers,
H.

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


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