[BioC] warning in lumi

Wed Feb 22 21:07:05 CET 2012

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

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

In what sense are "those days behind us"?

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