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
