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

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.

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.

Le 18/11/10 22:31, Douglas Bates a ?crit :

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.

You can use .property instead of .field to short circuit x back to d_x.

Consider this class (which I believe follows the convention you mention):

class Simple {
public:

Simple( double x ) : d_x(x){} ;

const double& x(){ return d_x ;}

private:
double d_x ;

} ;

In R, you'd want to be able to do :

r <- new( Simple, 10 )
r$x

but not :

r$x <- 20



Then .property is what you need:

RCPP_MODULE(mod){

class_<Simple>( "Simple" )

.constructor(init_1<double>())
.property( "x" , &Simple::x )

;
}


When the third argument is not given, the property is considered read only.

Romain

Le 18/11/10 22:31, Douglas Bates a ?crit :

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.

You can use .property instead of .field to short circuit x back to d_x.

Consider this class (which I believe follows the convention you mention):

class Simple {
public:

? ?Simple( double x ) : d_x(x){} ;

? ?const double& x(){ return d_x ;}

private:
? ?double d_x ;

} ;

In R, you'd want to be able to do :

r <- new( Simple, 10 )
r$x

but not :

r$x <- 20



Then .property is what you need:

RCPP_MODULE(mod){

? ? ? ?class_<Simple>( "Simple" )

? ? ? ? ? ?.constructor(init_1<double>())
? ? ? ? ? ?.property( "x" , &Simple::x )

? ? ? ?;
}


When the third argument is not given, the property is considered read only.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

Thanks again Romain.  Now that you mention it I remember.

On Thu, Nov 18, 2010 at 3:41 PM, Romain Francois
<romain at r-enthusiasts.com>  wrote:

Le 18/11/10 22:31, Douglas Bates a ?crit :

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.

You can use .property instead of .field to short circuit x back to d_x.

Consider this class (which I believe follows the convention you mention):

class Simple {
public:

    Simple( double x ) : d_x(x){} ;

    const double&  x(){ return d_x ;}

private:
    double d_x ;

} ;

In R, you'd want to be able to do :

r<- new( Simple, 10 )
r$x

but not :

r$x<- 20



Then .property is what you need:

RCPP_MODULE(mod){

        class_<Simple>( "Simple" )

            .constructor(init_1<double>())
            .property( "x" ,&Simple::x )

        ;
}


When the third argument is not given, the property is considered read only.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube