-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[Merged by Bors] - Make arrays behave like lists in reflection #5987
[Merged by Bors] - Make arrays behave like lists in reflection #5987
Conversation
crates/bevy_reflect/src/path.rs
Outdated
let list_index = value.parse::<usize>()?; | ||
let list_item = reflect_arr.get(list_index).ok_or( | ||
ReflectPathError::InvalidListIndex { | ||
index: current_index, | ||
list_index, | ||
}, | ||
)?; | ||
current = list_item; |
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.
Realistically, since List
is a subtrait of Array
, you should be able to extract this logic out and use it both lists and arrays.
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.
you are right, I missed that. Will rework.
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.
I was not able to combin the match branches themself, but move the inner logic in a function that accepts a &T where T: Array
, which seems to work fine.
Is there a smarter way to do this?
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.
Nope that's how I'd do it!
Although, I’d actually use &(mut) dyn Array
rather than T
since we don't really have a true concrete type
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.
I tried that, but as far as I understand, we'd need feature(trait_upcasting)
for that, right?
At least when I try it with this very simple example it fails in the same way: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9a17c93739790d86fd0f57a1452140c3
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.
Oh right haha then ignore what I suggested!
Since List is a supertrait of Array, we can treat both the same.
f0ccb66
to
7cfa74e
Compare
bors r+ |
# Objective Currently, arrays cannot indexed using the reflection path API. This change makes them behave like lists so `x.get_path("list[0]")` will behave the same way, whether x.list is a "List" (e.g. a Vec) or an array. ## Solution When syntax is encounterd `[ <idx> ]` we check if the referenced type is either a `ReflectRef::List` or `ReflectRef::Array` (or `ReflectMut` for the mutable case). Since both provide the identical API for accessing entries, we do the same for both, although it requires code duplication as far as I can tell. This was born from working on #5764, but since this seems to be an easier fix (and I am not sure if I can actually solve #5812) I figured it might be worth to split this out.
Pull request successfully merged into main. Build succeeded: |
# Objective Currently, arrays cannot indexed using the reflection path API. This change makes them behave like lists so `x.get_path("list[0]")` will behave the same way, whether x.list is a "List" (e.g. a Vec) or an array. ## Solution When syntax is encounterd `[ <idx> ]` we check if the referenced type is either a `ReflectRef::List` or `ReflectRef::Array` (or `ReflectMut` for the mutable case). Since both provide the identical API for accessing entries, we do the same for both, although it requires code duplication as far as I can tell. This was born from working on bevyengine#5764, but since this seems to be an easier fix (and I am not sure if I can actually solve bevyengine#5812) I figured it might be worth to split this out.
# Objective Currently, arrays cannot indexed using the reflection path API. This change makes them behave like lists so `x.get_path("list[0]")` will behave the same way, whether x.list is a "List" (e.g. a Vec) or an array. ## Solution When syntax is encounterd `[ <idx> ]` we check if the referenced type is either a `ReflectRef::List` or `ReflectRef::Array` (or `ReflectMut` for the mutable case). Since both provide the identical API for accessing entries, we do the same for both, although it requires code duplication as far as I can tell. This was born from working on bevyengine#5764, but since this seems to be an easier fix (and I am not sure if I can actually solve bevyengine#5812) I figured it might be worth to split this out.
# Objective Currently, arrays cannot indexed using the reflection path API. This change makes them behave like lists so `x.get_path("list[0]")` will behave the same way, whether x.list is a "List" (e.g. a Vec) or an array. ## Solution When syntax is encounterd `[ <idx> ]` we check if the referenced type is either a `ReflectRef::List` or `ReflectRef::Array` (or `ReflectMut` for the mutable case). Since both provide the identical API for accessing entries, we do the same for both, although it requires code duplication as far as I can tell. This was born from working on bevyengine#5764, but since this seems to be an easier fix (and I am not sure if I can actually solve bevyengine#5812) I figured it might be worth to split this out.
Objective
Currently, arrays cannot indexed using the reflection path API.
This change makes them behave like lists so
x.get_path("list[0]")
will behave the same way, whether x.list is a "List" (e.g. a Vec) or an array.Solution
When syntax is encounterd
[ <idx> ]
we check if the referenced type is either aReflectRef::List
orReflectRef::Array
(orReflectMut
for the mutable case). Since both provide the identical API for accessing entries, we do the same for both, although it requires code duplication as far as I can tell.This was born from working on #5764, but since this seems to be an easier fix (and I am not sure if I can actually solve #5812) I figured it might be worth to split this out.