<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. We did get to the bottom of the posted issue -- R packages that use modules need to import the whole Rcpp namespace.<div><br></div><div>I'm not quite sure what the parallel between reference classes and modules are here -- Rcpp modules allow you to basically expose C++ classes to R with a relatively minimal amount of boilerplate; of course you can write your own R functions (maybe as part of a reference class) to do the same, but the techniques are in the end different.</div><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; other methods are going to lean towards being more R-centric. I can't really call one method 'better' or 'worse'; they're just different. (I guess one downside of Rcpp modules is the use of external pointers, which implies they do not serialize / deserialize well?)</div><div><br></div><div>Kevin<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 8:40 PM, Christian Gunning <span dir="ltr"><<a href="mailto:xian@unm.edu" target="_blank">xian@unm.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Dear List,<br><br></div>The following is a general request for advice / comment on modern Rcpp development best-practices for package & class development. I looked over the Rcpp gallery, and didn't see anything obvious  that answers my questions  - perhaps this discussion could serve as a prototype for a new post?<br></div><br></div><div>## Background<br><br></div>I've used Rcpp modules for several projects where in-place modification was required for performance reasons. I   like the interface - it encourages clean code, and yields a nice mix of performance and encapsulation.<br><br>In the past, the lack of serialization has been a minor annoyance. Honestly, it's not something I need, but   I  dislike having invalid objects in the work-space after a quit/restart. I've spent a little time  thinking about work-arounds, which essentially boil down to moving back and forth from an R list object.<br><br></div><div>Looking towards the future, I also looked at the recent Rcpp  dev history. It looks like modules has had some  maintenance issues - for 
example, the last edits there (i..e,  PR 454) were reverted due 
to Windows toolchain issues (i.e., 
<a href="https://github.com/RcppCore/Rcpp/issues/463" target="_blank">https://github.com/RcppCore/<wbr>Rcpp/issues/463</a>).  From my  outside perspective, it appears that the modules code is A) hard, and B) not a current dev priority.<br></div><div><br></div><div>## A possible alternative: RefClass<br></div><div><br>I'm able to achieve similar behavior (in-place modification 
using named methods, relatively tidy code) using a combination of R 
RefClasses and Rcpp attributes. This solves the issue of serialization, and yields reasonably clean code. This has the added benefit of allowing easy mixing of R and C++ code in class methods.  <br><br>From a user perspective, RefClass methods are a nice place for   Rcpp functions that modify args in-place,
 since RefClass implies side-effects. And, in terms of style, if all C++ method functions  return void, and have const-correct arglists, then the C++ function signatures provide something of a interface spec.<br><br></div><div>Minimal example: <br><a href="https://gist.github.com/helmingstay/17d5d9f241c4170a29d1681db0111065" target="_blank">https://gist.github.com/<wbr>helmingstay/<wbr>17d5d9f241c4170a29d1681db01110<wbr>65</a><br><br><div><br>## Summary of observations:<br></div><div><br>* RefClass + attributes achieves similar outcomes to Rcpp modules, with somewhat better  support (serialization, documentation, future?).<br></div><br>* Unique to Rcpp modules is the ability to  auto-magically generate RefClass-like R bindings for existing C++ class-based code.<br><br>* For "mere mortals",  Rcpp modules now look less attractive for 
routine use, given available alternatives (i.e. for anything but binding
 auto-generation)<br><br><br></div><div>## Questions: <br><br></div><div>A) Any obvious problems with the above observations?<br></div><div><br>B) Are there any *gotchas*  with using Rcpp "modify-in-place" functions inside RefClass methods?<br></div><div><br>C) Is anyone else doing this? Any suggested improvements on the above?<br><br></div><div>Thanks much,<br></div><div>Christian Gunning<span class="HOEnZb"><font color="#888888"><br>-- <br><div class="m_-6766626213036231857gmail_signature">A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!</div>

</font></span></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/rcpp-devel</a><br></blockquote></div><br></div></div></div>