get_forecast_unit() currently relies on an internal call to get_protected_columns() to identify which columns it should ignore. These are currently things like quantile_level and sample_id.
This all works well within the current package. But once you start adding new classes then maybe that won't work so well anymore. I think what we should do is add a protected_columns argument to get_forecast_unit() and friends such that you could manually define which columns are protected. Similarly for set_forecast_unit(). Probably as_forecast() needs a ... arg.
Not proposing we do that now, but if we're serious about allowing users to write their custom classes, then we should likely do that at some point.
(get_forecast_type() may be another candidate for some additional tweaking, as well as the collapse argument for get_forecast_counts())
get_forecast_unit()currently relies on an internal call toget_protected_columns()to identify which columns it should ignore. These are currently things likequantile_levelandsample_id.This all works well within the current package. But once you start adding new classes then maybe that won't work so well anymore. I think what we should do is add a
protected_columnsargument toget_forecast_unit()and friends such that you could manually define which columns are protected. Similarly forset_forecast_unit(). Probablyas_forecast()needs a...arg.Not proposing we do that now, but if we're serious about allowing users to write their custom classes, then we should likely do that at some point. (
get_forecast_type()may be another candidate for some additional tweaking, as well as thecollapseargument forget_forecast_counts())