C++ modules should start using setters and getters about basilisk

[schaubh]

@juan-g-bonilla , I just pushed my setter/getter branch to feature/bsk_715_setterGetter. I'm able to log the private variables now with the get method. However, I wonder if we should make a new utility function in sys_model.i called loggerGet() that logs specifically a variable foo with the method getFoo()? If setters and getters are becoming the norm, then I feel we should make this logging process easier.

Or, can we expand the logger() functionality to see if the variable can be accessed via mod.foo. If not, then try using mod.getFoo(). If that doesn't work, then throw the current error message? That way the logging interface for public variables and getter accessible private variables remains the same?

[juan-g-bonilla]

bsk_715_setterGetter

I see the issue now. The thing is that because we are using raw C arrays, we need to return them from functions as pointers:

double * getFoo();

but then SWIG does not have enough information to transform that into a Python type (because it doesn't know the length of the data). There is really no way to return something like this in C++:

double[3] getFoo();

So we would need to use a more information rich type. I've added some commits with a switch to using std::array<double, 3> and SWIG changes to support that. I've also updated .logger with your idea about automatically finding getters, and it seems to work pretty good. As long as the documentation explains what's going on, I think it's a good change. Feel free to reset and play around with my changes.

Changing from C arrays to std::array might require some code churn, but I think it's step in the right direction anyway. Of course C arrays will still be necessary in C messages, but intermixing C arrays and std::array is pretty painless.

[schaubh]

Thanks for the support @juan-g-bonilla . I pulled your commits to my branch and will review and integrated. I like the new combined logger() functionality. I think this is a clean solution for the user. I need to update documentation to reflect this, and still keep the explanation on how to do more complex logging.