[BioC] warning in lumi
Martin Morgan
mtmorgan at fhcrc.org
Thu Feb 23 14:43:06 CET 2012
On 02/23/2012 03:38 AM, Francesco Mancuso wrote:
> Martin,
> many thanks for the explanations!
> But still in the lumi version 2.7.3 the warning persist.
>
> Warning message:
> Functions for exporting methods must have been made generic, explicitly
> or implicitly; not true when loading ‘lumi’ for ‘summary’
Bioconductor builds its packages on a daily basis; wait until version
2.7.4 is available, hopefully at 9:30am PST. Martin
>
> Best,
> Francesco
>
> > sessionInfo()
> R Under development (unstable) (2012-02-22 r58461)
> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-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.3 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 bigmemory_4.2.11 BiocInstaller_1.3.7
> Biostrings_2.23.6 BSgenome_1.23.2
> [9] DBI_0.2-5 DNAcopy_1.29.0 GenomicRanges_1.7.25
> genoset_1.4.15 grid_2.15.0 hdrcde_2.15
> IRanges_1.13.24 KernSmooth_2.23-7
> [17] lattice_0.20-0 MASS_7.3-17 Matrix_1.0-4
> mgcv_1.7-13 nlme_3.1-103 preprocessCore_1.17.1
> RSQLite_0.11.1 xtable_1.6-0
> [25] zlibbioc_1.1.1
>
>
> On 22/02/2012 21:39, Martin Morgan wrote:
>> 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
>>>>>>>
>>>>>>
>>>>
>>
>
> --
>
> *Francesco Mattia Mancuso*
> Bioinformatician
>
> - Bioinformatics Core Facility
> - Proteomics Core Facility
>
> CRG-Centre for Genomic Regulation (Room 439)
> C/ Dr. Aiguader, 88 (Edif. PRBB)
> 08003 Barcelona, Spain
>
> Mail: francesco.mancuso at crg.eu <mailto:francesco.mancuso at crg.eu>
> Phone: +34 933160202
> http://www.crg.es/bioinformatics_unit
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
More information about the Bioconductor
mailing list