<div dir="ltr"><div><div>All,<br>Thanks  for the comments, much appreciated. <br>To summarize what I'm hearing:<br></div><br>A) No major problems with the described approach<br></div>B) Not much evidence for previous use of this approach<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 29, 2016 at 12:02 PM, Kevin Ushey <span dir="ltr"><<a href="mailto:kevinushey@gmail.com" target="_blank">kevinushey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div dir="ltr">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.</div></div></blockquote><div><br>Thanks, that answers one big question.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"> We did get to the bottom of the posted issue</div></div></blockquote><br></div><div class="gmail_quote">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".<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div><br>
</div>
<div>I'm not quite sure what the parallel between reference classes and modules are here </div></div></div></blockquote><div><br></div><div>For a *user*, the resulting behavior is very similar.<br><br>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].<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div><br></div><div>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; </div></div></div></blockquote><div><br></div><div>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.<br><br>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 :)<br><br></div><div>best,<br></div><div>Christian<br></div></div><br>-- <br><div class="gmail_signature">A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!</div>
</div></div></div></div></div>