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

[Christian Gunning]

Whit,

I see that this could be useful in similar situations where Rcpp modules
excels (generating R bindings to existing C++ classes). Language preference
aside, it's less clear to me what advantage this approach (or Rcpp modules)
offers average users over RefClasses + Rcpp functions, where the RefClass
holds state, and the Rcpp functions operate on the state using by-reference
semantics.

-Christian

On Tue, Nov 29, 2016 at 5:33 AM, Whit Armstrong <armstrong.whit at gmail.com>
wrote:

> Have a look at this project:
> https://github.com/richfitz/RcppR6
>
>
> On Mon, Nov 28, 2016 at 11: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
>>
>
>


-- 
A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20161130/d89219dc/attachment-0001.html>