Søren Højsgaard <[EMAIL PROTECTED]> 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
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
