Skip to content

setGeneric(); R CMD check

5 messages · John Chambers, David James

Original
David James
# 
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?
_                           
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
John Chambers
#
David James wrote:
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.
...................

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.
Yes.  I'll add it to the online help for INSTALL (& the extensions
document?).

John

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      John Chambers
    

    

      
      #
    

  


  

      
John Chambers wrote:

        
................

            

      
      
      
    

        
By the way, an additional annoyance is that even with --SAVE, this
doesn't quite work always, because the `require("methods")' is only
active at INSTALL time, not when the image is loaded.  It would be nice
to make this carry over automatically as well, but how?

For now, the programmer needs to include the require("methods") in a
First.lib function in the package.



John
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      John Chambers
    

    

      
      #
    

  


  

      
Just to wrap up this thread, for now.

A section has been added to ?INSTALL with hints on installing packages
that use the methods package:

     Packages that require the methods package, and that use functions
     such as `setMethod' or `setClass', should be installed by creating
     a binary image.

     The package should require the methods package, both during
     installation and when the user attaches the package.  A good
     solution for most cases is to include the line
     `require("methods")' twice, once at the beginning of the package's
     R source, and once in the file `install.R' in the package
     directory (the top-level directory, not in the `R' directory below
     that).  The `install.R' file causes an image to be saved, and the
     contents will ensure that methods are available when the package
     is attached.

The suggestions seem to work, at least on some simple tests.  I'm not
aware of situations where this fails, but let me know otherwise.

The documentation should be in the next beta or rsync,  also in the
windows INSTALL help file (but I don't have a way to test that), plus a
pointer in the R-exts document to the online help page.

John

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      David James
    

    

      
      #
    

  


  

      
John, 

Thanks for the solution.

Your suggestion seems to work quite nicely and the added paragraphs
to help(INSTALL) are clear.  However, it seems that most people will
not be aware of this issue, and if and when they stumble into it,
looking at ?INSTALL may not be their first thought.  I'm wondering
if it would be helpful to include a similar description (or point to
?INSTALL) in, say, "Writing R Extensions", and/or ?setMethod, etc.?
A line in the Release Notes may also be helpful?

--
David

        
John Chambers wrote: