Skip to content

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

5 messages · Michael Lawrence, Steve Lianoglou, Hervé Pagès

Original
Steve Lianoglou
# 
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.

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.

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

Thanks,
-steve
Hervé Pagès
# 
Hi Steve,
On 11-11-04 02:02 PM, Steve Lianoglou wrote:
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.
In devel? Sure. It's a perfect time to break things ;-) I'm not so sure
about release though. What other people think?
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.

Cheers,
H.

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    
2 days later

    

      
      

        


  

        

      Steve Lianoglou
    

    

      
      #
    

  


  

      
Hi Herve & Michael:

2011/11/4 Michael Lawrence <lawrence.michael at gene.com>:

            

      
      
      
    

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

            

      
      
      
    

        
I'm fine w/ only adding it to devel if that's ok w/ everyone.

And Michael:

            

      
      
      
    

        
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 see ... not sure what exactly you mean by that, but perhaps I missed
a relevant thread discussing the expectations of a generics
operations?

-steve

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Hi Steve,

        
On 11-11-06 08:34 PM, Steve Lianoglou wrote:

            

      
      
      
    

        
something(object, ...)<- 'something'

            

      
      
      
    

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