[Developer Issue]: Should we be using //[[Rcpp::export]]?

[Andrea-Havron-NOAA]

Issue details

Currently, FIMS manually exposes class members and functions through R in inst/include/interface/rcpp_interface.hpp. Should we be using Rcpp's built-in functionality of //[[Rcpp::export]] instead?

[msupernaw]

@Andrea-Havron-NOAA We could certainly extend the interface module to have top-level functions to initialize life history components. For example, instead of recruitment<- new(BevertonHolt) we could instantiate with a top-level function like recruitment<-FIMS::CreateBevertonHolt(). I think it's a group preference issue.

On Mon, Jul 24, 2023 at 12:15 PM Andrea-Havron-NOAA < @.***> wrote:

Issue details

Currently, FIMS manually exposes class members and functions through R in inst/include/interface/rcpp_interface.hpp. Should we be using Rcpp's built-in functionality of //[[Rcpp::export]] instead?

— Reply to this email directly, view it on GitHub https://github.com/NOAA-FIMS/FIMS/issues/427, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFUSEEKCCIOXYRV3HWYPITXR2NTRANCNFSM6AAAAAA2V2DBCA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Matthew Supernaw Scientific Software Developer National Oceanic and Atmospheric Administration Office Of Science and Technology NOAA Fisheries | U.S. Department of Commerce Phone 248 - 396 - 7797

[ChristineStawitz-NOAA]

See here for more: https://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-modules.pdf

I don't think we can export the class members like fields or methods using the Rcpp::export tag, so there are two options to use the tag:

1. Add functions to set classes like CreateBevertonHolt() - this could make it easier for functional programmers to interact with modules
2. Replace all of the Rcpp module functionality with functions such that the modules themselves are not exposed through R, only the functions.

Option 1 is minimal work but not sure how much we would use it, Option 2 would potentially increase understanding for functional programmers who could ignore more of the OOP concepts when calling modules, but we'd need to discuss the benefits of that over using R functions to set the class methods and fields.

[msupernaw]

I think option 1 is best simply because there may be a time when the end user might want to use the fims namespace to differentiate from other code. Keeping both would require minimum work, so option 1 is my vote.

On Tue, Jul 25, 2023 at 1:45 PM Christine Stawitz - NOAA < @.***> wrote:

See here for more: https://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-modules.pdf

I don't think we can export the class members like fields or methods using the Rcpp::export tag, so there are two options to use the tag:

1. Add functions to set classes like CreateBevertonHolt() - this could make it easier for functional programmers to interact with modules
2. Replace all of the Rcpp module functionality with functions such that the modules themselves are not exposed through R, only the functions.

Option 1 is minimal work but not sure how much we would use it, Option 2 would potentially increase understanding for functional programmers who could ignore more of the OOP concepts when calling modules, but we'd need to discuss the benefits of that over using R functions to set the class methods and fields.

— Reply to this email directly, view it on GitHub https://github.com/NOAA-FIMS/FIMS/issues/427#issuecomment-1650276551, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFUSEGGUBLZUDMU3CKB6LTXSAA3LANCNFSM6AAAAAA2V2DBCA . You are receiving this because you commented.Message ID: @.***>

-- Matthew Supernaw Scientific Software Developer National Oceanic and Atmospheric Administration Office Of Science and Technology NOAA Fisheries | U.S. Department of Commerce Phone 248 - 396 - 7797