I believe Dr. Ripley said that the UseDynLib doesn't address the middle two points of the list.
I experimented with the Delaporte package timing calls using both methods, and they were within 1~2 microseconds of each other using microbenchmark. Since the more complicated way is now expressly preferred, it isn't a big deal for me personally to change so the next version of Delaporte will use CallMethod/useDynLib(foo, .registration=TRUE) etc. I can see how in more complicated packages that could become more burdensome. Thanks, Avi On Wed, Feb 22, 2017 at 9:34 AM, Jeroen Ooms <jeroen.o...@stat.ucla.edu> wrote: > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel