[Rd] an unpleasant interaction of environments and generic functions

[Uwe Ligges]

Ross Boylan wrote:

> I've run into an unpleasant oddity involving the interaction of
> environments and generic functions.  I want to check my diagnosis, and
> see if there is a good way to avoid the problem.
> 
> Problem:
> A library defines
> "foo" <- function(object) 1
> setMethod("foo", c("matrix"), function(object) 30)
> 
> After loading the library
> foo(0) is 1
> foo(matrix()) is 30
> foo is a generic
> 
> The source the file with the code given above.
> Now 
> foo(matrix()) is 1
> foo is a function
> (Also, there is no "creating generic function" message).
> 
> Diagnosis:
> The library creates foo and related generics in package:libname.
> The source for the initial definition puts the name and function
> definition in .GlobalEnv.
> The source'd setMethod finds the existing generic in package:libname and
> updates it (I'm not sure about this last step).
> foo then discovers the foo in .GlobalEnv, not the generic, so the
> generic and the alternate methods are hidden.
> 
> In case you're wondering, I found this out because I was experimenting
> with a library, changing the R and not the C code.  I get sick of doing
> R CMD INSTALL with each iteration, but needed to load the library to get
> the .so file.
> 
> So, is my diagnosis correct?
> 
> Any suggestions about how to avoid this problem?
> Maybe sys.source("file", 2)... Seems to work!


I'd suggest to dyn.load() the .so and source() the code during early 
development. So you do not need to R CMD INSTALL the _*package*_ into a 
library.

Uwe Ligges