All, Thanks for the comments, much appreciated. To summarize what I'm hearing:
A) No major problems with the described approach B) Not much evidence for previous use of this approach On Tue, Nov 29, 2016 at 12:02 PM, Kevin Ushey <kevinus...@gmail.com> wrote: > To be brief -- Rcpp modules are effectively in maintenance mode at this > point; we don't plan to extend / improve modules beyond resolving issues if > and when they come up. > Thanks, that answers one big question. > We did get to the bottom of the posted issue > Yes, I realize that. My point was that PR 454 remains un-merged, meaning that the last attempted modules code work was ultimately unfruitful. It can be challenging for end-users to distinguish between projects / code that is "fully functional but no longer under active development" (ok) from directions that code that is "unofficially deprecated". > I'm not quite sure what the parallel between reference classes and modules > are here > For a *user*, the resulting behavior is very similar. One big point is Rcpp's by-reference semantics, which has caused perennial confusion for users coming from a purely R background. Of course, by-reference semantics of Rcpp provides a big potential speed-up, but yields R functions that commonly confuse new users. And yes, both Rcpp functions and RefClasses are *labeled* with strongly worded warnings. Still, RefClasses introduce novel R style & semantics. I strongly suspect users are less likely to be surprised when "the_obj" is modified in-place by a call to "the_obj$rcpp_add(1)" [RefClass, Rcpp modules] versus "rcpp_add(the_obj, 1)" [Rcpp attributes, non-const args]. > > In sum, I think Rcpp modules are more geared towards developers who are > primarily C++ programmers who just want a super-simple way to expose a C++ > class to R; > As a point of reference, I *literally* learned Cpp OO to use Rcpp modules (thanks Romain!). This was quite a while ago, and I don't think Rcpp attributes were around yet. Also, R RefClasses were still new, and no one was talking about them. I really *liked* the Rcpp modules interface, but I still don't really understand it. As far as I can tell, the approach I describe here allows me to achieve the same end-goal as Rcpp modules with a similar amount of effort using tools under active development. The broader question of "best practices" remains - the Rcpp docs have expanded considerably over the years (it even has a book!). A number of great vignettes describing many "best practices" - in particular, I found a recent re-read of the attributes vignette to be *very* helpful. I didn't see much discussion of my particular question of how best to fit these parts together. If I'm the only one interested in this, so be it :) best, Christian -- A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
