On Tue, Feb 14, 2017 at 5:25 PM, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote: > > 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. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
