[BioC] warning in lumi

Wed Feb 22 21:39:00 CET 2012

On 02/22/2012 12:07 PM, Kevin R. Coombes wrote:
> I am now really confused. (This is, perhaps, not an unusual state.)
>
> I just checked the documentation in R2.14.1, which is still the current
> release. The three function "standardGeneric", "isGeneric" and
> "setGeneric" are still there. The example NAMESPACE information in page
> 36 of "Writing R Extensions" include the following lines taken from the
> "stats4" package:
>
> export(mle)
> importFrom("graphics", plot)
> importFrom("stats", optim, qchisq)
> ## For these, we define methods or (AIC, BIC, nobs) an implicit generic:
> importFrom("stats", AIC, BIC, coef, confint, logLik, nobs, profile,
> update, vcov)
> exportClasses(mle, profile.mle, summary.mle)
> ## All methods for imported generics:
> exportMethods(coef, confint, logLik, plot, profile, summary, show,
> update, vcov)
> ## implicit generics which do not have any methods here
> export(AIC, BIC, nobs)
>
> It also explicitly claims that "exporting methods on a generic in the
> namespace will also export the generic, and
> exporting a generic in the namespace will also export its methods".

These are both true statements.

I would say that the next lines

"If the generic function is not local to this package, either because it 
was imported as a generic function or because the non-generic version 
has been made generic solely to add S4 methods to it (as for functions 
such as plot in the example above), it can be declared via either or 
both of export or exportMethods"

are no longer accurate, as evidenced by the warning message that started 
this thread. I would also say that, if the remedy to the warning has 
been to use setGeneric("plot"), then the next clause

"but the latter is clearer (and is used in the stats4 example above)"

would not reflect my opinion -- the generic is being exported, along 
with its newly-adorned methods.

> Also, even when I am using BioConductor, I am often also using
> non-BioConductor packages (that might create their own generic version
> of plot, because R core still only supplies S3 generics and not S4
> generics for everything -- or at least the obvious things).

yes, you might choose to import a non-BiocGenerics generic to add your 
method to, or to create your own generic and export that, or use the 
generic provided by BiocGenerics, all of these are possible and until 
plot is made an S4 generic in R, all will introduce multiple versions of 
the plot generic. Choosing to use BiocGenerics reduces conflicts with 
other Bioconductor packages, without having any further deterimental 
consequences for non-Bioc packages -- at least a partial if not complete 
win, with no down-sides.

The 'if(!isGeneric("plot"))' construct implies that you do not want to 
rely on imports, but instead on the search path (because otherwise you 
would know whether plot was a generic or not, without having to 
determine that in your code). This opens up any number of possible 
problems, for instance that the plot generic on the search path has been 
defined with different default behaviors or to dispatch on different 
arguments than the method that you'd like to introduce.

> In what sense are "those days behind us"?

I meant the days of not having a name space.

Martin

>
> On 2/22/2012 1:43 PM, Martin Morgan wrote:
>> 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