[Rcpp-devel] Designing Rcpp modules - allow access to fields or to field accessor methods?

[Andrew Redd]

Isn't this sort of thing what the .property is for in modules?  Or are
you looking for something else
-Andrew

On Thu, Nov 18, 2010 at 2:31 PM, Douglas Bates <bates at stat.wisc.edu> wrote:
> My C++ coding style (such as it is) has been influenced by reading
> Frank Bokken's "C++ Annotations".  I keep most data members of classes
> private or protected and usually with names like d_x, d_y, d_weights,
> etc. then provide accessor functions named x, y, weights, etc.
> Generally the accessors return const references.
>
> If I export such a class in an Rcpp module I can't allow field access
> but can allow access from R to the accessor methods.  This seems
> slightly awkward in that the user must know to use
>
> myRefObj$x()
>
> instead of
>
> myRefObj$x
>
> to access the x field.  Any strong opinions about fields access versus
> access to field accessor methods?
>
> As an example, one of my classes ends up looking like this
>
>> getRefClass("Rcpp_lmResp")
> Generator object for class "Rcpp_lmResp":
>
> No fields defined
>
>  Class Methods:
>    "callSuper", "export", "finalize", "import", "initFields",
> "initialize", "mu",
> "offset", "sqrtrwt", "sqrtXwt", "updateMu", "updateWts", "wrss", "wtres", "y"
>
>
>  Reference Superclasses:
>    "envRefClass"
>
> but all those methods except updateMu and updateWts are field accessors.
>
> One advantage of this method is that one can't make changes to those
> fields at the R level, which I like because I am paranoid about
> introducing inconsistencies in the fields.
> _______________________________________________
> 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
>