1. Is it always the case that when defining generic functions in
a package, the package needs to be installed as a binary package
to avoid having the generic functions in the .GlobalEnv?
2. Defining a generic function in a "non-binary" package triggers
a check warning
$ R CMD check ...
...
* checking for code/documentation mismatches ... WARNING
Objects with usage in documentation object 'dbApply' but missing
from code:
[1] "dbApply"
It seems that the generic function dbApply lives in the .GlobalEnv when
the package is attached (w. library), but not in the package's
environment.
I presume that's why check triggers the warning.
Is this the case?
*If* this is the case (i.e., packages with setGeneric()s need to be installed
as binaries), perhaps it should be documented somewhere.
... or am I missing something very basic?
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status Under development (unstable)
major 1
minor 6.0
year 2002
month 09
day 09
language R
--
David A. James
Statistics Research, Room 2C-253 Phone: (908) 582-3082
Bell Labs, Lucent Technologies Fax: (908) 582-3340
Murray Hill, NJ 09794-0636
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
John Chambers
2002-Sep-11 13:46 UTC
Installing packages using methods: was Re: setGeneric(); R CMD check
David James wrote:> > 1. Is it always the case that when defining generic functions in > a package, the package needs to be installed as a binary package > to avoid having the generic functions in the .GlobalEnv?By "binary", meaning "INSTALL --save" or equivalent? Yes, and the symptom you mentioned is rather mild, compared to what will often happen! Any of the computations that default to assigning metadata to the global environment will cause problems (setMethod, setClass, ...) in a default installation, unless all such computations are wrapped in a function call that can be re-directed from the .First.lib function to the correct environment. It's not likely to be worth the effort. For the present version of R, the simplest approach is probably for the programmer to arrange for an installation with a saved image, either through the option to INSTALL or by putting a file "install.R" (an empty file will do) in the top source directory of the package. For the next version, we should try to make the process more automatic, although the only way that would always work seems to be by making --save the default to INSTALL.> > 2. Defining a generic function in a "non-binary" package triggers > a check warning >................... As mentioned, the "CMD check" problem may be the least of it! The following snippet will _apparently_ install with or without --save: ### Dummy Package require("methods") foo <- function(x)x setGeneric("foo") setMethod("foo", "character", function(x) paste("++", x)) ### But in the default install, it fails (annoyingly) when the library is attached, because the assignment of foo is not in the search list, so setGeneric doesn't find any definition of "foo". R> library(DummyPackage) Loading required package: methods Error in setGeneric("foo") : Must supply a function skeleton, explicitly or via an existing function It's possible to work around most of the specific problems, but my feeling is that the natural semantics for the programmer is that the same source code should work basically the same way, whether being sourced into the global environment for initial testing or being installed as a package.> *If* this is the case (i.e., packages with setGeneric()s need to be installed > as binaries), perhaps it should be documented somewhere. >Yes. I'll add it to the online help for INSTALL (& the extensions document?). John> -- > David A. James > Statistics Research, Room 2C-253 Phone: (908) 582-3082 > Bell Labs, Lucent Technologies Fax: (908) 582-3340 > Murray Hill, NJ 09794-0636 > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._-- John M. Chambers jmc@bell-labs.com Bell Labs, Lucent Technologies office: (908)582-2681 700 Mountain Avenue, Room 2C-282 fax: (908)582-3340 Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._