On 11-02-16 4:29 AM, Janko Thyson wrote:
Dear List,
I'm trying to figure out some best practice way with respect to the naming
conventions when building own packages.
I'd like to minimize the risk of choosing function names that might
interfere with those of other packages (both available ones and those yet to
come).
I came up with following alternatives
1. Prefixing the actual names (e.g. myPkgfoo() instead of foo()): pretty
verbose
Another verbose solution is to use descriptive names for your functions.
Then you'll only clash with functions that are trying to do the same
thing.
2. Emulating a package namespace while developing and explicitly using
myPkg::foo() in all scripts: IMHO the best way, but apparently not possible
as I learned.
Is it really a problem when developing? Surely you can control which
other packages are loaded, and just choose names that don't clash with
those? The real problem with name clashes comes when your package is
out in the wild, and a user wants to use your package and an unrelated
one at the same time. If you both have a foo() function that user's
scripts could change depending on the search order.
3. Carefully choosing which functions to export. Yet, I'm not sure I
completely understand the implications of exported functions. Does this
imply that not exported functions cannot interfere with functions in other
namespaces?
You should definitely do this. Functions which are not exported will
not be visible to other packages without a prefix, so they won't clash.
Your package will be guaranteed to see its own functions first. A
user can still have a clash between your exported functions and some
other package's exports, but with fewer functions exported, that will
not be as much of a problem.
Duncan Murdoch
I'd be great to hear some recommendations on this one!
Thanks a lot,
Janko
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
