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 <[email protected]> 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 > [email protected] > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > _______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
