[Bioc-devel] Making GenomicRanges::genome generic more generic ...

[Steve Lianoglou]

Hi Herve & Michael:

2011/11/4 Michael Lawrence <lawrence.michael at gene.com>:
>
>
> 2011/11/4 Hervé Pagès <hpages at fhcrc.org>
>>
>> Hi Steve,
>>
>> 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.

I guess we share different opinions of what "awkward" means :-)

Going backwards: is it possible to have `...` in a setter anyway? I
mean, I guess I don't see where `...` would go in:

something(object) <- 'something'

though I do see `...` in the def for `setReplaceMethod` ... hmm.

anyway, with respect to (1) I'd argue that it's better err on the side
of things that "might be" (even if they don't yet exist in the
bioc-universe). Especially with functions as "generic" (excuse the
overloaded term -- here I mean non-specificly named) as a function
named "genome" (vs. "exonsByOverlaps") ... not that I'm arguing
anything, it seems like you're open to adding it back in to devel
(which is fine by me).

>>> 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'm fine w/ only adding it to devel if that's ok w/ everyone.

And Michael:

> Do we really need to modify every method? I think changing the generic is
> all that is really necessary.

I wasn't sure if packages would pass checks if the generic defines a
function to take `...` but a setMethod() didn't include the `...` If
it's not necessary, then I wouldn't suggest modifying every method, I
was just anticipating the worst.

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

I see ... not sure what exactly you mean by that, but perhaps I missed
a relevant thread discussing the expectations of a generics
operations?

-steve

-- 
Steve Lianoglou
Graduate Student: Computational Systems Biology
 | Memorial Sloan-Kettering Cancer Center
 | Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact