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’

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@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@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@crg.eu <mailto:francesco.mancuso@crg.eu>
Phone: +34 933160202
http://www.crg.es/bioinformatics_unit

	[[alternative HTML version deleted]]

