-
Notifications
You must be signed in to change notification settings - Fork 2.1k
get_layer_data(), get_layer_grob() can use layer names #6724
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
Conversation
…to layer-names
teunbrand
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the PR! I agree that being able to use the name to get layer data/grob would be useful. I think it'd make more sense to merge to name approach in this PR with i. Using vctrs::vec_as_location2() to construct the index would handle both the integer and named cases.
|
Thanks, I didn't know that helper existed! Now the parameter |
teunbrand
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for these updates, I like the direction of the PR!
Now the parameter i is a bit inconsistent with get_panel_scales() since it indexes into panels instead of layers.
I agree that it is unlikely to be an issue.
teunbrand
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the contribution and putting up with our comments! I've taken the liberty of implementing the test proposals and adding a news bullet.
|
Thanks, sorry but I had no time to finalize! |
|
No worries, we're glad you contributed the main parts! |
A tiny PR that builds upon #5967.
Now the names can be used by
get_layer_data()andget_layer_grob()in place of the layer index.Only scalars are accepted, just like the current behavior.
If a name is supplied, it is used, but the layer must exist.
If both the name and the index are supplied (either explicitly or as a default argument), the name takes precedence.
The names must be unique (this is currently enforced by #5967 — should revisit whether this is no longer the case).
Perhaps it's better to make
iandnamemutually exclusive, likeidandnumberforrecipes::tidy.recipe()?