Need `enable_deltamethod()` for `Calculation` subclasses even when not supported
brews opened this issue · comments
The enable_deltamethod() method required to be implemented for Calculation subclasses even when not supported by the math. This was brought up in PR #31.
This feels like a framework design issue.
If a Calculation doesn't support deltamethod then it shouldn't have this method. I think we can handle this in a more graceful way. I suggest that we write a concrete deltamethod mixin class (DeltaMethodMixin). In short, we inherit from this mixin whenever a calculation supports deltamethod. It won't be a required part of Calculation interface and the calculation will only have the deltamethod attributes if this run type is supported by the actual math.
A second issue is that this enable_deltamethod() method specifically feels like a fuzzy implementation of getter/setter accessor method in a C++/Java-y way. A nice Pythonic approach might be to have a public deltamethod attribute, we can use @property decorators to control access to the attribute. This can easily support the old-school way so this change won't break backwards compatibility.
I think I can draw up a PR with these changes and run it by @jrising . I think it would be relatively simple. It would help clean up and clarify the package and its interfaces.
Looking for feedback from @jrising. Any interest in this?
@brews I don't see the advantage to what you describe, and actually think that every class should implement an enable_deltamethod function, as spec'd.
If I were doing this in Java, I would include a throws UserError declaration on this function. There are two issues here: (1) If it is not possible to enable the deltamethod on a Calculation, only that Calculation knows why. But it should provide that information, and force the processing to stop. Remember that some Calculation objects will sometimes be able to use the delta method, depending on their properties: If a Calculation object optionally has clipping, then it may be able to use the delta method unless clipping is enabled. (2) Lots of Calculation classes "pass-through" the delta method enabling to their subcalcs. We would have to check if the mixin is available all the way through. So, it makes for messier code, doesn't provide useful information, and just forcing some other class to do the exception throwing, since we still want to throw an exception up to whoever asked us to enable it.
So, there's a difference between the enable_deltamethod not being implemented, and being implemented to throw a useful error. And if someone leaves the method as non-implemented, that's always a problem, because it should either work, or a useful exception should be thrown.
We might also not want to think of enable_deltamethod like setting a property, although it does mutate the Calculation. The job of that function is to do whatever is necessary to prepare the calculation object to do potentially very different calculations with different inputs.
One possible improvement would be to have this logic occur at the point of application. So, we could replace enable_deltamethod with a apply_deltamethod method, which returns a potentially distinct Application instance than the normal apply method would.
Can we close this?
Yeah, okay, I see your issue. Thanks for taking the time to explain your thinking. Will open new issue if we need to revisit/clarify this.