ModelParameters needs proper encapsulation.

[iago-lito]

I somewhat worry that:

• upcoming changes to address Pre-defined parametrization of the model #69..
• upcoming changes to feature new functional form for producers growth (Nutrient intake #113)..
• any upcoming, non-monotonically-increasing changes to ModelParameters struct..

.. will eventually trigger a lot of churn because, as of today, all user code relies on explicit, direct accesses to ModelParameters fields. For parameter x for instance, access is either parms.x or parms.biorates.x or parms.environment.x or parms.functional_response.x or parms.producer_competition.x etc. The first downside of this is that it's not always easy to understand where to find x. The second downside is a bigger problem, because every future change to ModelParameters is potentially breaking.

Starting now, I suggest that we stop exposing ModelParameters fields to user and offer instead a whole bunch of abstract, controlled accesses like:

• x = get_x(parms) for read-only accesses. The resulting x is a copy of internal parameters and can be modified by the user without altering the state of parms.

• set_x!(parms, value) for write-only accesses. The value of parms is modified accordingly and all internal checks can be run.

• x = ref_x!(parms) for aliasing accesses (read/write). The resulting x is a direct reference to internal parameters and can be modified to alter the state of parms. Use with caution.

This essentially boils down to adding a large list of such methods somewhere in the package sources. To ease the transition, all package code with direct parms.x accesses can remain as-is in a first time. But all tests/docs/doctests need to be rewritten to use get_x(parms) etc. instead, so the user won't rely on parms.x.

With this out of the way, future evolutions of ModelParameters should not become an endless source of dread, fear and nightmares ;) Also, it would nicely leverage with #73.

[alaindanet]

I am excited to see that happening!!

[iago-lito]

Well, I was actually planning on maybe asking whether you would be happy to be assigned to this issue, after we're done with #87? :)

[iago-lito]

Or I can have a shot at it.. because it may be not as trivial as it sounds? I'm concerned whether we should wait on #113 to happen first, so as to not trigger to much churn for you @evadelmas?

[iago-lito]

Alé, #113 is moving closer to the finish line. I'll start the work on this :)

[iago-lito]

Featured by #131.