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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel