Skip to content

[Bioc-devel] Candidates for BiocGenerics

19 messages · Kevin Coombes, Sean Davis, Martin Morgan +3 more

Original
Benilton Carvalho
# 
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?

benilton
Sean Davis
# 
On Thu, Mar 1, 2012 at 7:57 AM, Benilton Carvalho
<beniltoncarvalho at gmail.com> wrote:
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
Kevin Coombes
# 
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?
      Kevin
On 3/1/2012 10:18 AM, Sean Davis wrote:
Hervé Pagès
# 
Hi Benilton, Sean,
On 03/01/2012 08:18 AM, Sean Davis wrote:
I agree.
Not that I know of.

I'll add boxplot, coef, image, ncol and residuals to BiocGenerics today.
I'll also add nrow, NROW, NCOL and dim, which are all interconnected
with ncol.

Cheers,
H.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Benilton Carvalho
    

    

      
      #
    

  


  

      
Thank you very much Herve! cheers, b

2012/3/1 Herv? Pag?s <hpages at fhcrc.org>:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Sean Davis
    

    

      
      #
    

  


  

      
2012/3/1 Herv? Pag?s <hpages at fhcrc.org>:

            

      
      
      
    

        
Thanks.  Is it worth developing an SOP or policy statement that can go
either here:

http://bioconductor.org/developers/package-submission/

or here:

http://bioconductor.org/developers/package-guidelines/

A link to currently available generics, how to request a new generic,
and some guidance to package developers about using the available
generics might be useful information?

Sean

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Hi Kevin,

        
On 03/01/2012 10:13 AM, Kevin R. Coombes wrote:

            

      
      
      
    

        
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.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Martin Morgan
    

    

      
      #
    

  


  

      
On 03/01/2012 10:20 AM, Herv? Pag?s wrote:

            

      
      
      
    

        
I had not really been aware that 'stats4' plays the same kind of role, 
in a limited sense, in base R. So for these

 > grep("^[^.]", getNamespaceExports("stats4"), value=TRUE)
  [1] "AIC"     "BIC"     "coef"    "confint" "logLik"  "mle"     "nobs"
  [8] "plot"    "profile" "show"    "summary" "update"  "vcov"

one would like instead to Imports: stats and importFrom(stats, plot) 
etc. This means that recent changes to add plot and summary to 
BiocGenerics should be undone...

Martin

 >

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Nicolas Delhomme
    

    

      
      #
    

  


  

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

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?

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:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
On 03/01/2012 10:55 AM, Martin Morgan wrote:

            

      
      
      
    

        
Arghh... good catch! OK, I'll remove plot and summary from BiocGenerics.
That also means that I don't need to add coef there.

H.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Hi Nico,

        
On 03/01/2012 11:05 AM, Nicolas Delhomme wrote:

            

      
      
      
    

        
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?

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 (+, -, *).

Anyway, yes it seems to make sense to move the strand() generic to
BiocGenerics so I will to 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).

Cheers,
H.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Nicolas Delhomme
    

    

      
      #
    

  


  

      
On 1 Mar 2012, at 21:11, Herv? Pag?s wrote:

        

            

      
      
      
    

        
Kind of; it's not really an union, but I do use both of some of their functionalities.

            

      
      
      
    

        
You name it ;-)

            

      
      
      
    

        
Great! I'll see with Julien if he can adapt to that.

            

      
      
      
    

        
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.

Cheers,

Nico

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Done in BiocGenerics 0.1.10.

Summary:

   - Removed plot and summary generics (already defined in stats4).

   - Added nrow, ncol, NROW, NCOL, boxplot, image and residuals generics.

   - Didn't add coef (already defined in stats4).

   - Didn't add dim either because it's an "internal generic primitive"
     function (like length(), dimnames(), `dim<-`, `dimnames<-`, etc...,
     see ?InternalMethods for the complete list) so it's not needed.

   - Added a note in ?BiocGenerics about how to request addition of a
     new generic to the package.

Benilton, 'R CMD check BiocGenerics' will produce a warning because I
put the following invalid link in the man pages for boxplot and image:

   \link[oligoClasses]{FeatureSet}

(please do ?BiocGenerics::image so see the context).

The reason I put this link is that, for every generic, I'm trying to
provide a link to one of the existing methods and also a link to the
class for which this method is defined. In the case of boxplot and
image, the man page points to the method for FeatureSet and this
class is defined in the oligoClasses package, hence the link.
However, for this link to be valid, the FeatureSet alias would need
to be added somewhere in the man pages of the oligoClasses package
(in FeatureSetExtensions-class.Rd it seems).
Can you please take care of this?

I know I could use something like \link[oligoClasses]{FeatureSet-class}
and that link would be valid but...

More generally speaking I'd like to encourage developers to make
?SomeClass work for their class. Many beginners have no idea they need
to do class?SomeClass or ?`SomeClass-class` in order to get to
the man page for a class and ?SomeClass is less typing anyway.
You could argue that class?SomeClass should be for the class and
?SomeClass for the SomeClass() function but this function, if defined,
should be the constructor for that class and it's probably a good idea
to document it in the same man page as the class. So, to summarize,
putting

\alias{SomeClass-class}
\alias{SomeClass}

in the man page for the SomeClass class makes its documentation a little
bit easier to access for a very small extra cost.

Cheers,
H.

        
On 03/01/2012 10:24 AM, Benilton Carvalho wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
On 03/01/2012 12:21 PM, Nicolas Delhomme wrote:

            

      
      
      
    

        
Done in BiocGenerics 0.1.10

            

      
      
      
    

        
Even better, I suggest you bring this case on R-devel to get reduce
added to stats4 ;-)

Cheers,
H.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Nicolas Delhomme
    

    

      
      #
    

  


  

      
Great! I'll see what I can do.

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 2 Mar 2012, at 11:30, Herv? Pag?s wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    
3 days later

    

      
      

        


  

        

      Benilton Carvalho
    

    

      
      #
    

  


  

      
Thanks, Herve, for everything.. I'll fix oligoClasses so you dont' get
the warning on BiocGenerics.

Additionally, for a second round of inclusions, could you [please
consider adding 'weights' to BiocGenerics as well?

Thank you very much,

benilton

2012/3/2 Herv? Pag?s <hpages at fhcrc.org>:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Hi Benilton,

        
On 03/05/2012 08:13 AM, Benilton Carvalho wrote:

            

      
      
      
    

        
Done in BiocGenerics 0.1.13.

Note that there doesn't seem to be any method defined in Bioconductor
for weights() yet. Please let me know when you add one so I can provide
a link to it in the man page for the generic. Thanks!

H.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Benilton Carvalho
    

    

      
      #
    

  


  

      
Hi Herve,

thanks again for this!

Both affyPLM and oligo have methods for weights().

b

2012/3/7 Herv? Pag?s <hpages at fhcrc.org>:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
On 03/07/2012 12:33 AM, Benilton Carvalho wrote:

            

      
      
      
    

        
Thanks! Link added in ?BiocGenerics::weights.

Note that both packages would need to be modified to import the
weights() generic from BiocGenerics and to export the "weights"
methods they implement.

Cheers,
H.