How to keep backwards compatibility for wrapper functions

[gustavdelius]

Since its inception, mizer had three "wrapper functions" -- functions for setting up MizerParams objects with default values: set_community_model(), set_trait_model() and MizerParams(), for consistency also available as set_multispecies_model(). Each of these chooses default values for parameters that the user does not specify. Now we have become unhappy with several of those choices for defaults.

1. We changed the defaults for h, the coefficient of the maximum intake rate, to ensure that fish reach their maturity size at the correct age.
2. We changed the default for ks, the coefficient of basic metabolic rate, to ensure that a species stops being viable at a critical feeding level of 0.2, see Improve default for metabolic rate #101 .
3. I am proposing to change the default for m, the exponent of the proportion of available energy that is invested into reproduction to better match the mizer growth curve to the von Bertalanffy growth curve, see Default value for exponent in allocation to reproduction #108 .
4. @Kenhasteandersen is proposing changes to several other defaults to match those more carefully chosen in his new book.

Currently these changes are turned on only when the user sets options(mizer_new = TRUE). That mechanism however can lead to confusion, as we experienced in Lysekil recently. So please make recommendations for how you think we should keep backwards compatibility for these wrapper functions. Or argue in favour of dropping backwards compatibility for the wrapper functions.

Note that is a completely separate issue from the backwards compatibility of the project() method. The issue discussed here only affects the setting up of MizerParams objects.

[gustavdelius]

A simple and obvious solution just occurred to me: we should simply introduce new names for the wrapper functions that implement the new defaults and keep the old wrapper functions as they are.

This works nicely because the old wrapper functions also used a naming convention that is different from the naming convention we use for most user-facing functions in mizer, for which we use camel case. So I propose that we introduce new versions of the wrapper functions called

• newCommunityParams()
• newTraitParams()
• newMultispeciesParams()

The fourth wrapper function set_scaling_model() , which was introduced only recently and creates a scale-invariant version of the trait-based model, could become newTraitModel(..., scaling = TRUE).

[gustavdelius]

For consistency, the function in the new mizer that creates an empty MizerParams object and is currently called emptyParams() should really be called newEmptyParams() although that is unimportant because users should never have to use it.

[Kenhasteandersen]

That solution would be fine with me. I would also bring consistency to the naming scheme of functions. I would even be ok with “retiring” the old functions, as I don’t think they are widely used anyway. We could keep them, but add a warning that they are based on dated parameter values. Ken

…

--------------------------------------------------------------------------------------------------------------- Ken H. Andersen, http://ken.haste.dk<http://ken.haste.dk/>, twitter: @69kno Professor in theoretical marine ecology, head of section, and deputy director of Centre for Ocean Life http://www.oceanlifecentre.dk<http://www.oceanlifecentre.dk/> New book: Fish Ecology, Evolution, and Exploitation - A New Theoretical Synthesis https://press.princeton.edu/titles/13516.html [cid:image001.jpg@01D09493.A377DFB0] On 19 Sep 2019, at 17.34, Gustav W Delius <notifications@github.com<mailto:notifications@github.com>> wrote: A simple and obvious solution just occurred to me: we should simply introduce new names for the wrapper functions that implement the new defaults and keep the old wrapper functions as they are. This works nicely because the old wrapper functions also used a naming convention that is different from the naming convention we use for most user-facing functions in mizer, for which we use camel case. So I propose that we introduce new versions of the wrapper functions called * newCommunityModel() * newTraitModel() * newMultispeciesModel() The fourth wrapper function set_scaling_model() , which was introduced only recently and creates a scale-invariant version of the trait-based model, could become newTraitModel(..., scaling = TRUE). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#109?email_source=notifications&email_token=ADFHLALCCSFMEHE7NN4EVMTQKOLZFA5CNFSM4IYMTSBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7D4WIQ#issuecomment-533187362>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADFHLAN2BUO7EGT7GJYEZG3QKOLZFANCNFSM4IYMTSBA>.

[juliablanchard]

Good idea to introduce new functions with the revised parameters to ensure backwards compatibility. I think we should keep the “set...model” functions ( at lest for a little while) as otherwise people will need to charge their code (including teaching material) , but add a notification that these have been replaced with “ new... model” and I would suggest a notification about the changed parameter values too.

…

________________________________ From: Kenhasteandersen <notifications@github.com> Sent: Monday, September 23, 2019 6:58 am To: sizespectrum/mizer Cc: Subscribed Subject: Re: [sizespectrum/mizer] How to keep backwards compatibility for wrapper functions (#109) That solution would be fine with me. I would also bring consistency to the naming scheme of functions. I would even be ok with “retiring” the old functions, as I don’t think they are widely used anyway. We could keep them, but add a warning that they are based on dated parameter values. Ken

--------------------------------------------------------------------------------------------------------------- Ken H. Andersen, http://ken.haste.dk<http://ken.haste.dk><http://ken.haste.dk/<http://ken.haste.dk/>>, twitter: @69kno Professor in theoretical marine ecology, head of section, and deputy director of Centre for Ocean Lifehttp://www.oceanlifecentre.dk<http://www.oceanlifecentre.dk><http://www.oceanlifecentre.dk/<http://www.oceanlifecentre.dk/>> New book: Fish Ecology, Evolution, and Exploitation - A New Theoretical Synthesishttps://press.princeton.edu/titles/13516.html<https://press.princeton.edu/titles/13516.html> [cid:image001.jpg@01D09493.A377DFB0] On 19 Sep 2019, at 17.34, Gustav W Delius <notifications@github.com<mailto:notifications@github.com>> wrote: A simple and obvious solution just occurred to me: we should simply introduce new names for the wrapper functions that implement the new defaults and keep the old wrapper functions as they are. This works nicely because the old wrapper functions also used a naming convention that is different from the naming convention we use for most user-facing functions in mizer, for which we use camel case. So I propose that we introduce new versions of the wrapper functions called * newCommunityModel() * newTraitModel() * newMultispeciesModel() The fourth wrapper function set_scaling_model() , which was introduced only recently and creates a scale-invariant version of the trait-based model, could become newTraitModel(..., scaling = TRUE). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#109?email_source=notifications&email_token=ADFHLALCCSFMEHE7NN4EVMTQKOLZFA5CNFSM4IYMTSBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7D4WIQ#issuecomment-533187362<https://github.com/sizespectrum/mizer/issues/109?email_source=notifications&email_token=ADFHLALCCSFMEHE7NN4EVMTQKOLZFA5CNFSM4IYMTSBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7D4WIQ#issuecomment-533187362>>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADFHLAN2BUO7EGT7GJYEZG3QKOLZFANCNFSM4IYMTSBA<https://github.com/notifications/unsubscribe-auth/ADFHLAN2BUO7EGT7GJYEZG3QKOLZFANCNFSM4IYMTSBA>>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#109?email_source=notifications&email_token=ABGD7OTR6YZM55WNMHOLGTLQLBLI5A5CNFSM4IYMTSBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7J3MXI#issuecomment-533968477>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABGD7OUFEEBHNCIJXAZ6V7TQLBLI5ANCNFSM4IYMTSBA>. University of Tasmania Electronic Communications Policy (December, 2014). This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

[gustavdelius]

We will definitely keep the old deprecated functions around, at least for a few versions. We could handle deprecation the same way the tidyverse does it, see https://www.tidyverse.org/lifecycle/. Relevant code to generate the notifications is at https://github.com/r-lib/rlang/blob/master/R/compat-lifecycle.R