[Bioc-devel] Making GenomicRanges::genome generic more generic ...
hpages at fhcrc.org
Sat Nov 5 00:21:02 CET 2011
On 11-11-04 02:02 PM, Steve Lianoglou wrote:
> Hi all,
> It looks like the `genome` generic function from rtracklayer has moved
> to GenomicRanges in the 2.9 release train, and subsequently lost its
> `...` param.
I moved it, together with the `genome<-` generic, and dropped the `...`
arg from `genome` because (1) I couldn't find any method in BioC
that uses this arg, (2) `genome` (getter) and `genome<-` (setter)
are aimed to be accessors and it's unusual to have `...` in an
accessor, (3) it was a little bit ackward to have `...` in the getter
but not in the setter.
> Would anybody mind if I add the `...` back to the genome function now
> defined in GenomicRanges? I'll be careful to update the setMethods
> where appropriate in GenomicRanges, but I guess other packages will
> also need to update (rtracklayer) that I can't commit to.
In devel? Sure. It's a perfect time to break things ;-) I'm not so sure
about release though. What other people think?
> I was `importFrom(rtracklayer, genome)`-ing the genome function in one
> of my packages ... switching it to importFrom GenomicRanges isn't a
> problem, but I use the `...`
> (here's another post that touches on the "need" for a centralized
> BiocGenerics (or whatever) package that pops up from time to time).
Not every generic is going to make it to BiocGenerics. Also a generic
function is not just a name, there are also some expectations about what
kind of operation its methods should do.
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