xclim.core.missing should be refactored to use a functional programming approach

[Zeitsperre]

Addressing a Problem?

The xclim.core.missing submodule currently contains several classes and subclasses that are being used to provide functions with shared behaviours, thanks to class inheritance. In practice, this means that a MissingBase can be used to provide a set of common behaviours, which are then used for different types of Missing checks, whose docstrings and methods are used in order to build:

• missing_any()
• missing_wmo()
• missing_pct()
• at_least_n_valid()
• missing_from_context()

There are a few issues with this approach:

• The current implementation sees unequal adoption of the standards of subclasses (e.g. calling super().__init__()) as in most cases, this isn't needed.
• The call signatures of the subclasses don't necessarily match those of their constructors or parent class (use of **kwargs for some; some variables listed but not used, etc.).
• As class docstrings are being used to generate function docstrings, documentation checking tools can't effectively be used to ensure consistency (lots of false positives and typical standards need to be ignored).

I can't say for certain, but initializing a bunch of classes and subclasses to mimic a functional programming approach is probably more computationally taxing than adopting a strict functional programming approach.

Potential Solution

This module could use a full refactoring to adopt functional approaches.

Additional context

Issue raised from work done in #1988.

Contribution

• I would be willing/able to open a Pull Request to contribute this feature.

Code of Conduct

• I agree to follow this project's Code of Conduct

[coxipi]

Sarah was also discussing (I think) how pre-processing such as jitter_under_thresh could also adopt this approach, although I'm not sure we want to go there. I think that pre-processing data in this way is a bit different, but shares some simliarities with the idea of pre-checks before doing computation.

I feel this might be a Pandora's box in some way, but I can't really tell where things could go wrong. At least for tests, it's maybe a bit more difficult to evaluate the coverage of such functionalities. If it has the potential of greatly simplifying some things, I'd say it's worth a shot.