My point regarding the clang parser is that one really shouldn't have to
write any R or Rcpp wrappers at all.
If one directly parses the c++ class then both the R6/RefClass/List (or
whatever implementation one chooses to use) and the C wrappers (which we
will still need as we can't expose the c++ class directly to R; we still
need .Call) can be generated directly from parsing the class w/ clang.
Rcpp modules uses chaining to do this, but one still has to write this code:
Rcpp::class_<Redis>("Redis")
.constructor("default constructor")
.constructor<std::string>("constructor with host port")
.constructor<std::string, int>("constructor with host and port")
.constructor<std::string, int, std::string>("constructor with host
and port and auth")
.constructor<std::string, int, std::string, int>("constructor with
host and port, auth, and timeout")
.method("exec", &Redis::exec, "execute given redis command and
arguments")
...
richfitz/RcppR6 uses some yaml to generate the bindings, which one has to
provide and keep it synchronized w/ the class.
circle:
constructor:
args: [radius: double]
methods:
area:
return_type: double
active:
circumference:
name_cpp: circumference
name_cpp_set: set_circumference
access: member
type: double
radius: {access: field, type: double}
we should be able to extract all that from the class itself w/ clang.
That's the point.
-Whit
On Wed, Nov 30, 2016 at 5:49 AM, Christian Gunning <x...@unm.edu> wrote:
> 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.w...@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 <x...@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@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!
>
_______________________________________________
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
