Closed nikosbosse closed 3 months ago
@seabbs you're in favour of this, right? @Bisaloo @jamesmbaazam @sbfnk do you have opinions?
The proposed approach will produce a lot of duplicated code. I prefer the existing approach.
I think the upside is it makes it more obvious to users how to write their own new method and it makes it look more "standard"/ As @jamesmbaazam says though it would be a lot of replicated code if a internal function wasn't used.
The benefit of the first solution is that you can (cleanly) create a forecast of a given type programmatically.
type <- "sample" # actually passed by the user or determined by a more complex code than this
new_forecast(data, type)
The second solution requires jumping through convoluted hoops:
type <- "sample"
do.call(paste0("new_forecast_", type), list(data))
So I would say it mostly depends on how frequently you expect this situation.
I vote for the existing approach as well. Fine to close for now and potentially revisit in the future?
Please feel free to reopen!
We currently have a single
new_forecast
function which creates a new forecast object of the appropriate class via an argumentclassname
which accepts a string.Alternatively we could have separate
new_forcast<type>
for the separate forecast typesCurrent implementation is:
new implementation would probably be something like