Re: [Rd] an unpleasant interaction of environments and generic functions

From: Uwe Ligges <>
Date: Wed 01 Feb 2006 - 07:49:51 GMT

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 mailing list Received on Wed Feb 01 18:54:35 2006

This archive was generated by hypermail 2.1.8 : Wed 01 Feb 2006 - 10:02:51 GMT