[Rcpp-devel] RFC: Rcpp modules vs. RefClass

[Kevin Ushey]

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.

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.

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?)

Kevin

On Mon, Nov 28, 2016 at 8:40 PM, Christian Gunning <xian at unm.edu> wrote:

> Dear List,
>
> 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?
>
> ## Background
>
> 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.
>
> 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.
>
> 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., https://github.com/RcppCore/Rcpp/issues/463).  From my
> outside perspective, it appears that the modules code is A) hard, and B)
> not a current dev priority.
>
> ## A possible alternative: RefClass
>
> 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.
>
> 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.
>
> Minimal example:
> https://gist.github.com/helmingstay/17d5d9f241c4170a29d1681db0111065
>
>
> ## Summary of observations:
>
> * RefClass + attributes achieves similar outcomes to Rcpp modules, with
> somewhat better support (serialization, documentation, future?).
>
> * Unique to Rcpp modules is the ability to auto-magically generate
> RefClass-like R bindings for existing C++ class-based code.
>
> * For "mere mortals", Rcpp modules now look less attractive for routine
> use, given available alternatives (i.e. for anything but binding
> auto-generation)
>
>
> ## Questions:
>
> A) Any obvious problems with the above observations?
>
> B) Are there any *gotchas* with using Rcpp "modify-in-place" functions
> inside RefClass methods?
>
> C) Is anyone else doing this? Any suggested improvements on the above?
>
> Thanks much,
> Christian Gunning
> --
> A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!
>
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20161129/523c2edd/attachment.html>