R devel - Feb 2011 - Avoiding name clashes: opinion on best practice naming conventions

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
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. 
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?

I'd be great to hear some recommendations on this one!

Thanks a lot,
Janko

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

On Wed, Feb 16, 2011 at 4:29 AM, Janko Thyson
<janko.thyson.rstuff at googlemail.com> 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
> 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.
Since the resolution of myPkg::foo() occurs at runtime (via a function
call) instead
of at compile time (as it would in C++), this practice can introduce a
significant
performance hit. This can be avoided by doing something like:
mylocalfunc <- myPkg::foo
[tight loop that uses mylocalfunc repeatedly]

Here mylocalfunc would not be exported, of course.

Dominick
> 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?
>
> 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
>