[uoaei]

To obfuscate the choice of algorithm behind kwargs (as opposed to creating separate classes) has always seemed to me a suspect choice, in sklearn as well as here. And it seems to make development of the package more complex at the expense of... less readable code for the user, with less flexibility for differences in hyperparameter specifications, etc.

There are of course exceptions, something like `TrendPredictor(order=1, interp="polynomial")` as an example can be flexibly adapted up or down the hierarchy of model complexity much easier than commenting out different lines.

[tony_bagnall]

I have taught machine learning in Java using Weka for a long time, and when we moved over to sklearn this also annoyed me. It made a good teaching point with, for example, decision trees having a dozen separate different classes for different algorithms in Weka and sklearn having one configurable one. I guess just design preference in the end. With aeon we are leaning more towards the one class per algorithm or algorithm family, but its not a hard and fast rule. One issue is when does a change in algorithm mean a change in class? So, for example, we have separate transformers for ROCKET, MINROCKET and MULTIROCKET (convolution transforms), but a single configurable RocketClassifier. UltimatelyI think it comes down to how comprehensible it is to a new user.