An interesting discussion comment was raised in #959. When Bmi_Multi_Formulation adopted the DataProvider interface and changed the signature of Bmi_Multi_Formulation::get_value and Bmi_Multi_Formulation::get_values to use a CatchmentAggrDataSelector param, it didn't just use that CatchmentAggrDataSelector param directly, e.g., in calls to a nested module's get_value. The multi-formulation function created a new CatchmentAggrDataSelector, based on the param, but with an explicitly set id. The id was empty in the first such revision of the code, although this was later changed to be the catchment id. But even then, the id was explicitly set in a new CatchmentAggrDataSelector.
Going forward from #959, we are assuming this is no longer necessary, and that appears to be the case after a quick assessment. Though, there also appears to be nothing to guarantee that will remain the case or protect against this changing in the future, perhaps unintentionally. The design should be improved to not be at risk for such regressions, at least without some warning mechanism in place (e.g., tests of some sort).
An interesting discussion comment was raised in #959. When Bmi_Multi_Formulation adopted the DataProvider interface and changed the signature of
Bmi_Multi_Formulation::get_valueandBmi_Multi_Formulation::get_valuesto use a CatchmentAggrDataSelector param, it didn't just use that CatchmentAggrDataSelector param directly, e.g., in calls to a nested module'sget_value. The multi-formulation function created a new CatchmentAggrDataSelector, based on the param, but with an explicitly set id. The id was empty in the first such revision of the code, although this was later changed to be the catchment id. But even then, the id was explicitly set in a new CatchmentAggrDataSelector.Going forward from #959, we are assuming this is no longer necessary, and that appears to be the case after a quick assessment. Though, there also appears to be nothing to guarantee that will remain the case or protect against this changing in the future, perhaps unintentionally. The design should be improved to not be at risk for such regressions, at least without some warning mechanism in place (e.g., tests of some sort).