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