> There is at least one subtle consequence to keep in mind when doing > this. Of course, whatever choice you make, if the whatever() function > moves to a different package, this breaks your package. > However, if you explicitly import the function, your package will > break at load-time (which is good) and you'll only have to modify > 1 line in the NAMESPACE file to fix it. But if you do foo::whatever(), > your package won't break at load-time, only at run-time. Also you'll > have to edit all the calls to foo::whatever() to fix the package. > > Probably not a big deal, but in an environment like Bioconductor where > infrastructure classes and functions can be shared by hundreds of > packages, having people use foo::whatever() in a systematic way would > probably make maintenance a little bit more painful than it needs to > be when the need arises to reorganize/refactor parts of the > infrastructure. Also, the ability to quickly grep the NAMESPACE > files of all BioC packages to see who imports what is very convenient > in this situation.
OTOH, I think there's a big benefit to being able to read package code and instantly know where a function comes from. Personally, I found this outweighs the benefits that you outline: * functions rarely move between packages, and gsubbing for pkga:foo to pkgb:foo isn't hard * it's not that much hard to grep for pkg::foo in R/* than it is to grep NAMESPACE Hadley -- http://had.co.nz/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
