Recently I got introduced to two packages: {seewave} and {audio} .
Turns out they both have a tool to call a system audio tool, and in both
cases the name of the tool is play(). Naturally these two tools do
slightly different things with different arguments.
So, what should a user do, and more to the point, what should R do? If
I've learned the right things about environments, I could include some
require() statements inside scripts to guarantee the right things are
loaded (and only loaded for that script).
But in general when there are two commands with the same name, it means
that if I distribute code which uses the command, a random user
elsewhere might have the other package loaded and bad things would happen.
In a perfect world, there would be some R control database that people
would check packages into. The database (or some poor volunteer) would
verify there were no naming conflicts with other posted packages, and so
on. Failing that, what are good rules for fail-safing code, or
figuring out how to check that some package I've loaded didn't blow away
some other tools I previously loaded?
Carl
See the "warn.conflicts" arguments of require() and library(). People
thought about this a long time ago.
-- Bert Gunter
-----Original Message-----
From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org]
On
Behalf Of Carl Witthoft
Sent: Friday, February 13, 2009 4:05 PM
To: r-help at r-project.org
Subject: [R] question about tool collisions
Recently I got introduced to two packages: {seewave} and {audio} .
Turns out they both have a tool to call a system audio tool, and in both
cases the name of the tool is play(). Naturally these two tools do
slightly different things with different arguments.
So, what should a user do, and more to the point, what should R do? If
I've learned the right things about environments, I could include some
require() statements inside scripts to guarantee the right things are
loaded (and only loaded for that script).
But in general when there are two commands with the same name, it means
that if I distribute code which uses the command, a random user
elsewhere might have the other package loaded and bad things would happen.
In a perfect world, there would be some R control database that people
would check packages into. The database (or some poor volunteer) would
verify there were no naming conflicts with other posted packages, and so
on. Failing that, what are good rules for fail-safing code, or
figuring out how to check that some package I've loaded didn't blow away
some other tools I previously loaded?
Carl
______________________________________________
R-help at r-project.org 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.
on 02/13/2009 06:05 PM Carl Witthoft wrote:> Recently I got introduced to two packages: {seewave} and {audio} . > Turns out they both have a tool to call a system audio tool, and in both > cases the name of the tool is play(). Naturally these two tools do > slightly different things with different arguments. > > So, what should a user do, and more to the point, what should R do? If > I've learned the right things about environments, I could include some > require() statements inside scripts to guarantee the right things are > loaded (and only loaded for that script). > But in general when there are two commands with the same name, it means > that if I distribute code which uses the command, a random user > elsewhere might have the other package loaded and bad things would happen. > > > In a perfect world, there would be some R control database that people > would check packages into. The database (or some poor volunteer) would > verify there were no naming conflicts with other posted packages, and so > on. Failing that, what are good rules for fail-safing code, or > figuring out how to check that some package I've loaded didn't blow away > some other tools I previously loaded?In addition to Bert's excellent recommendation (as well as ?conflicts), this is one of the key reasons for using namespaces. It would appear, from a review of the tarballs for both packages, that audio is using a namespace, but seewave does not. You might make a recommendation to the latter's author to implement a namespace for his package. That would help avoid the collisions in third party code. audio does export the play() function, so you can use: audio::play(...) to differentiate that function from: seewave::play(...) None of this is a guarantee of course, if other play() functions should be loaded or come into being, which is why namespaces are a safer approach. See also: http://cran.r-project.org/doc/manuals/R-intro.html#Namespaces HTH, Marc Schwartz