[Rd] Avoiding name clashes: opinion on best practice naming conventions

[Duncan Murdoch]

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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel