[Bioc-devel] Candidates for BiocGenerics
Nicolas Delhomme
delhomme at embl.de
Fri Mar 2 11:54:36 CET 2012
Great! I'll see what I can do.
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 2 Mar 2012, at 11:30, Hervé Pagès wrote:
> 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