Registration of native routines

On Tue, Feb 14, 2017 at 5:25 PM, Prof Brian Ripley

Registration has similar benefits to name spaces in R code:

- it ensures that the routines used by .C, .Call etc are those in your package (without needing a PACKAGE argument).
- it avoids polluting the search space for native routines with those from your package.
- it checks the number of arguments passed to .Call/.External, and the number and optionally the type for .C/.Fortran.
- it finds native routines faster, especially if 10s of name spaces are loaded.

Do these benefits also hold for packages that currently use useDynLib
exclusively in combination symbol names? E.g for the example from WRE:

   useDynLib(foo, myRoutine, myOtherRoutine)

Which is invoked via:

  .Call(myRoutine, x, y)

What ambiguity or pollution is introduced by foo:::myRoutine? Should
manually registering 'myRoutine' in C still be mandatory in this case?

It was nice having the NAMESPACE as the central declaration of
callable C routines. The "R_registerRoutines" system will require
maintaining additional C code which re-declares all callable C
functions from other compilation units. This introduces additional
complexity for package authors and might become a source of bugs when
we forget to update the registrations when C functions have changed.