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

[Hervé Pagès]

Hi Steve,

On 11-11-06 08:34 PM, Steve Lianoglou wrote:
> 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'

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.

Please test this. If that's the case that adding `...` to the generic
only doesn't break the methods and doesn't generate 'R CMD check'
warnings then I guess it's OK to do the change to release too.

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

I'm just saying that it's probably not a good enough reason to re-use
a name in your code just because it's a pretty name. The method you
define for an existing generic should also implement the kind of
operation conceptually associated with the generic (and this concept
should be described in the man page of the generic). If it's going
to do something different then it's better to use another name.
I'm not saying you should give up the "genome" name, I don't know
what it does.

Cheers,
H.

>
> -steve
>


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