Suppose, under this approach, we would tune an estimator that requires their forecasting horizon in fit.

What would happen?

The wrapped forecaster would complain that it needs the fh in fit.

are you sure? The complaining happens in fit, but we directly delegate to _fit which skips the wrapped forecaster's complaining.

Inside _fit we call the fit of the wrapped forecaster, so it would complain there, I think.

EDIT: Just checked, we actually call evaluate which calls fit from the passed forecaster. So it should complain.

Happy to approve this and to be merged, if in turn you are happy with #1099.

My proposed way forward would be:

• merge this using your suggestion, @mloning, to "get the refactor done"
• get the BaseObject refactor done too, but with basic machinery for dynamic tags in there.
• have the next release; don't use the dynamic tags anywhere in that, but have the base functionality in (in BaseObject). Note that we have already decided that we want this, see June 23 dev days discussion notes. It also follows your get_tag suggestion in the very PR, so I would hope this is uncontroversial.
• have discussions on tags, by estimator type - after the next release.

@fkiraly I haven't looked at #1099 yet. Is it okay to merge this to finish the refactor and then release and then work on tags for the new release?

Is it okay to merge this to finish the refactor and then release and then work on tags for the new release?

I'd prefer to have the refactor finished all up the inheritance tree in the release, i.e., including BaseObject.
Could you take some time to look at #1099 hence? It passes tests and would nicely wrap up @RNKuhns' work.

Otherwise, I'd have to ask for more time to think about the consequences of the refactor end state, perhaps have a discussion next week.
As said in the discussion on #1088, I think your solution adds broken behaviour regarding tags, without an obvious way out of it. I wouldn't have these concerns if the BaseObject is also in there.

Regarding working on tags, I agree to do work on them after the new release. That's precisely the point of my suggestions in #1099 - we would be ready for that in the new release if we have BaseObject sorted out. Note that my suggestion to BaseObject does not change any tag related logic in any concrete class. It simply implements the decision we took on June 23 (see above).

@fkiraly so can we merge this without merging the dynamic tags before the next release?

fine with me, but please do the merge(s) then yourself, in the way you prefer