[Rcpp-devel] R.e. loadRcppModules

[Dirk Eddelbuettel]

On 14 April 2011 at 07:49, Douglas Bates wrote:
| On Thu, Apr 14, 2011 at 12:43 AM, Christian Gunning <xian at unm.edu> wrote:
| > On Tue, Apr 12, 2011 at 11:07 PM, Romain Francois
| > <romain at r-enthusiasts.com> wrote:
| >>>
| >>> Just to clarify --  does your plan include storing user-modified
| >>> fields and properties in objects?  E.g. below, modtest with the msg
| >>> set?
| >>
| >> yes. Although the way I see it, this will require more work for the
| >> developper, who would have to provide a serialization/deserialization couple
| >> for his/her classes.
| >>
| >> This is a nice goal for a future version.
| >
| > Am I naive to think that a 1-to-1 mapping between C++ object fields &
| > properties and an S4 object might make sense?  This reduces the module
| > developer's problem of serial/deserialization to 1) writing a
| > constructor (and perhaps with validator) that takes an S4 object, and
| > 2) writing a finalizer that populates a specified S4 object in the
| > user's environment, tears down the C++ object (as per R Exts manual),
| > and let's save() do the rest?
| >
| > It seems that, in theory, there's a canonical mapping between the
| > names/types of fields/properties exposed in the RCPP_MODULE call and
| > the proposed S4 object.  The main gotcha I see here is that any
| > variable within a C++ object *not* exposed as a field/property must be
| > viewed as a const to ensure consistency of the C++ object between
| > write and re-construct...
| >
| > If this is off-base, feel free to ignore or point out good reading material :)
| 
| I don't think it is off-base.  I was planning something very similar
| to that except that not every field/property would be saved.  I have
| classes in which many of the properties are calculated on the fly and
| I don't need to save those.  I just need to save enough information to
| create the object again.
| 
| This approach would run into trouble if there were data fields in the
| C++ object that could not be expressed as R objects.  However, it
| seems to me that if the C++ object can be generated from R objects in
| the first place you should be able to serialize enough information to
| reconstruct it.

This really is darn close to what RProtoBuf does to fit into (Google's)
Protocol Buffers "everything to everyone" scheme reportedly used for all
intermachine (and interlanguage) communication.  But that would of course
introduce a new non-R dependency so you probably do not want that here.

So we'd have to reinvent a suitable subset, leaning on R's serialization.

Too bad we didn't have that insight four weeks ago. This would have made a
swell project for Google Summer of Code.  I blame Christian ;-)

Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com