[Bioc-devel] Candidates for BiocGenerics
Hervé Pagès
hpages at fhcrc.org
Thu Mar 1 21:11:33 CET 2012
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?
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 (+, -, *).
Anyway, yes it seems to make sense to move the strand() generic to
BiocGenerics so I will 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).
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