-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fully embrace vctrs for dynamic branching #1105
Comments
cc @kendonB, @billdenney, @brendanf |
I like it, and I think it'll make dynamic branching simpler to use. |
Awesome! Rethinking |
Good news: with |
4 tasks
3 tasks
This was referenced Jan 18, 2020
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Prework
drake
's code of conduct.Description
After writing out #1087 (comment), I think we should fully embrace
vctrs
for dynamic branching. It will technically be a breaking change for workflows that usereadd()
on dynamic targets in plans, but dynamic branching is so new that I am willing to let it slide. In the end, we gain type more type stability as described at https://vctrs.r-lib.org/articles/stability.html.We want
readd()
andloadd()
to be fully type-stable. Current behavior:Created on 2019-12-10 by the reprex package (v0.3.0)
Desired behavior:
We should be able to achieve similar type-stable aggregation across all types if we use
vctrs::vec_c()
inloadd()
andreadd()
. Similarly,dynamic_subvalue()
should just callvctrs::vec_slice()
. And as long as we depend onvctrs
, we should setmeta$size
tovctrs::vec_size()
instead ofNROW()
.The text was updated successfully, but these errors were encountered: