[BioC] warning in lumi

Wed Feb 22 20:43:03 CET 2012

On 02/22/2012 11:18 AM, Kevin R. Coombes wrote:
> 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?

This idiom is problematic. The rules are that if the developer promotes 
the function to a generic, then it needs to be documented (fair enough, 
the generic is not the same as the original). But the construct is 
conditional, so the documentation is only sometimes required. Further, 
if the developer promotes the generic, then they need to export the 
generic rather than the method, export(plot) rather than 
exportMethods(plot). Again this would be conditional with the above 
scenario.

Also, the developer is defining a method in their name space, and the 
developer has full control of the name space -- there is no need to 
determine at run time whether 'plot' is a generic or not; 
importFrom(graphics, plot) imports a non-generic, so the promotion would 
be required. It might be that plot has been promoted to a generic 
somewhere on the user search path, but relying on the user search path 
is not appropriate for a package; problems arise when a third package 
tries to import methods from an intermediate package (gory details 
available on request).

And finally, within Bioconductor, it makes sense to avoid name 
collisions as much as possible. So if the function has been promoted to 
a generic in BiocGenerics, then that is the preferred source for import 
-- importFrom(BiocGenerics, plot).

I think the conditional construct dates from pre-NAMESPACE days, when 
one really didn't have a choice. Those days are behind us.

Martin

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

-- 
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793