[BioC] warning in lumi

[Kevin R. Coombes]

Is this problem avoided by an explicit call to setGeneric in the R code 
of the package, in the usual idiom:

if (!isGeneric("plot"))
   setGeneric("plot", function(x, y, ...) standardGeneric("plot"))

or is there something else going on here that I don't understand?

On 2/22/2012 12:18 PM, Martin Morgan wrote:
> On 02/22/2012 09:16 AM, Martin Morgan wrote:
>> On 02/22/2012 07:56 AM, Francesco Mancuso wrote:
>>> Dear all,
>>> I am the author of a CRAN package (HumMeth27QCReport) that denpends on
>>> lumi.
>>> Every time I call the lumi package I obtain the following warning:
>>>
>>> "
>>> Functions for exporting methods must have been made generic,
>>> explicitly or implicitly; not true when loading ‘lumi’ for ‘summary’
>>> "
>>>
>>> Since this error comes not only when I try to build ny package but also
>>> when I require lumi from normal R command line, I think this is a
>>> problem in lumi package itself. Am I correct?
>>> Is there the possibility to solve it?
>>
>> Hi Francesco -- we are addressing these warnings in a number of Bioc
>> packages; this particular problem was fixed in the devel branch last
>> night. Martin
>
> Maybe to provide developers with a little insight on this --
>
> Previously, in a NAMESPACE file one might
>
>   importFrom(graphics, plot)
>
> 'plot' is a standard R function in graphics. and then somewhere in the 
> package code say
>
>   setMethod(plot, "MyClass", ...)
>
> This would implicitly promote 'plot' from a standard R function to an 
> S4 generic, and then associate a method for plotting instances of 
> MyClass. Common practice was to then add to the NAMESPACE
>
>   exportMethods(plot)
>
> This now generates a warning (soon to be an error, if I understand 
> R-core's intentions), because the plot method is exported without a 
> generic on which to export it. The solution is to explicitly create a 
> generic for 'plot', and to export (and document) that, as well.
>
> Several functions, including plot, are 'promoted' in this way 
> independently in different packages. This means that there would be 
> many separate plot generics on which to hang methods and the user 
> would potentially have to resolve dispatch to the package -- 
> lumi::plot(...). The BiocGenerics package has been developed to 
> provide a central location for generic definition, in hopes of 
> avoiding this conflict. The BiocGenerics package creates commonly used 
> generics, and these are made available to other packages. So the 
> changes to lumi are
>
>   1. Add Imports: BiocGenerics to the DESCRIPTION file
>   2. Add importFrom(BiocGenerics, plot) to the NAMESPACE file
>   3. Remove importFrom(graphics, plot) from the NAMESPACE file
>
> If the generic were not defined in BiocGenerics, the solution would be
>
>   0. Tell us (via the bioc-devel list) that foo should be in 
> BiocGenerics?
>   1. Introduce an explicit generic with setGeneric...
>   2. Perhaps provide an S3 version of the S4 method, see ?Methods
>   3. Export and document the explicit generic
>
> Martin
>
>>
>> r62969 | mtmorgan at fhcrc.org | 2012-02-21 20:37:50 -0800 (Tue, 21 Feb
>> 2012) | 6 lines
>>
>> code tidyup
>>
>> - avoid implicit plot, summary generic with BiocGenerics
>> - avoid partial matching
>> - remove empty documentation sections
>>
>>
>>>
>>> Many thanks,
>>> Francesco
>>>
>>>
>>> > sessionInfo()
>>> R Under development (unstable) (2012-01-30 r58238)
>>> Platform: i386-apple-darwin9.8.0/i386 (32-bit)
>>>
>>> locale:
>>> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> other attached packages:
>>> [1] lumi_2.7.2 nleqslv_1.9.2 methylumi_2.1.13
>>> Biobase_2.15.3 BiocGenerics_0.1.4
>>>
>>> loaded via a namespace (and not attached):
>>> [1] affy_1.33.2 affyio_1.23.1 annotate_1.33.1
>>> AnnotationDbi_1.17.15 BiocInstaller_1.3.7 DBI_0.2-5
>>> grid_2.15.0 hdrcde_2.15
>>> [9] IRanges_1.13.20 KernSmooth_2.23-7 lattice_0.20-0
>>> MASS_7.3-16 Matrix_1.0-3 mgcv_1.7-13
>>> nlme_3.1-103 preprocessCore_1.17.1
>>> [17] RSQLite_0.11.1 tools_2.15.0 xtable_1.6-0
>>> zlibbioc_1.1.1
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Bioconductor mailing list
>>> Bioconductor at r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/bioconductor
>>> Search the archives:
>>> http://news.gmane.org/gmane.science.biology.informatics.conductor
>>
>>
>
>