an unpleasant interaction of environments and generic functions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

an unpleasant interaction of environments and generic functions

Ross Boylan
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!
--
Ross Boylan                                      wk:  (415) 514-8146
185 Berry St #5700                               [hidden email]
Dept of Epidemiology and Biostatistics           fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739                     hm:  (415) 550-1062

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: an unpleasant interaction of environments and generic functions

Ross Boylan
On Tue, 2006-01-31 at 15:21 -0800, Ross Boylan wrote:

> Any suggestions about how to avoid this problem?
> Maybe sys.source("file", 2)... Seems to work!
Not quite.  The original versions of some stuff from the library hung
around, and my efforts to delete them led to more difficulties.

Specifically, after loading the library I deleted the names of the
generics and classes from the library's frame.  Then I read the source
files into the frame.  This time it complained there was no function by
the appropriate name when I tried to do setMethod, even though the
previous file should have created it.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: an unpleasant interaction of environments and generic functions

Uwe Ligges
In reply to this post by Ross Boylan
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel