[Bioc-devel] Candidates for BiocGenerics

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

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

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