Open Andrea-Havron-NOAA opened 1 year ago
@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
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:
CreateBevertonHolt()
- this could make it easier for functional programmers to interact with modulesOption 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.
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:
- Add functions to set classes like CreateBevertonHolt() - this could make it easier for functional programmers to interact with modules
- 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
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?