You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than having completely different APIs (e.g., apply vs impute) for Chain, Imputors, Filter, Validators, etc maybe we should just define a common API apply convention for all these types and distinguish them with functions like return_type, ccr (consume construct return), ismutating? We currently have mostly duplicated default behaviour for Imputors, Validators and declaremissings. This will just get worse once the current set of deprecations are completely removed. We also have only slight differences in the autogenerated functional API which could probably be simplified.
The text was updated successfully, but these errors were encountered:
rofinn
changed the title
Generalize apply, impute distinctions
Generalize apply vs impute distinctions
Oct 21, 2020
NOTE: Since this should mostly just reduce code duplicate and possible improve efficiency I don't think it'd be a breaking change to introduce in a future release. I'm going to leave this off the 0.6 milestone.
Rather than having completely different APIs (e.g.,
apply
vsimpute
) forChain
, Imputors, Filter, Validators, etc maybe we should just define a common APIapply
convention for all these types and distinguish them with functions likereturn_type
,ccr
(consume construct return),ismutating
? We currently have mostly duplicated default behaviour for Imputors, Validators and declaremissings. This will just get worse once the current set of deprecations are completely removed. We also have only slight differences in the autogenerated functional API which could probably be simplified.The text was updated successfully, but these errors were encountered: