[R] Over-writing functions from other packages? What is a good strategy??
Seth Falcon
sfalcon at fhcrc.org
Wed Mar 21 04:34:19 CET 2007
Søren Højsgaard <Soren.Hojsgaard at agrsci.dk> writes:
> I am writing a package which uses the Rgraphviz package which in
> turn uses the graph package, but my question does not (I believe)
> pertain specifically to the these packages so therefore I dare to
> post the question here:
>
> I my package I have a function "edges" which works on some graphs I
> have defined. However, there is also a function "edges" (or rather a
> generic method) in the graph package (seemingly written in S4).
Yes, edges is a generic function defined by the graph package. With
methods for various graph representation classes.
> I load my package the Rgraphviz package is automatically loaded, but
> this means that the edges method of the the graph package
> "overrides" the edge function in my package.
>
> Is there a way of avoiding this? If there is, I guess that it is a
> dangerous path to take? But if so, what else is a good strategy to
> take?
I'm pretty sure this is resolved by adding a NAMESPACE file to your
package (see the Writing R Extensions Manual for details).
I made a little test package that has Rgraphviz in Depends, defines an
edges function and exports it in its NAMESPACE file. When I load this
package, edges is the one from my test package and graph::edges is the
one from graph.
It won't solve your problem in general, but I will also look into
having Rgraphviz only import graph and not Depend on it. This would
avoid graph::edges polluting the search path when Rgraphviz gets
loaded. This is a reason that import might be preferred over Depends
for packages that have namespaces.
Finally, if you were depending on graph and not Rgraphviz, then you
could rename graph::edges when you import it in your NAMESPACE file:
importFrom("graph", someOtherName=edges)
+ seth
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
More information about the R-help
mailing list