-
-
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
Bevy Reflection #926
Bevy Reflection #926
Conversation
4adfad0
to
ba21f0b
Compare
Many of these high-level design changes look really great, and I'm looking forward to experimenting with this for scripting. Even the merging of the two previous crates is a big win for learnability and docs. |
Co-authored-by: memoryruins <memoryruinsmusic@gmail.com>
Maybe this helps: https://github.com/amethyst/serde-diff |
@jbarthelmes thanks! im relatively familiar with serde-diff. its nice, but the implementation is pretty different from what I'm planning. |
@cart is that supposed to be |
@CleanCut Yup good call. I just updated the pr description and ill update the markdown in my next pr. |
@cart are you aware of dtolnay's other crazy distributed aggregation crate |
@mrobakowski yeah I came across it during my investigation and the lack of WASM was a dealbreaker. |
I'll be watching the space. As soon as we have a cross-platform option I'll jump on it 😄 |
Bevy Reflect
This crate replaces the old
bevy_property
andbevy_type_registry
crates with a new, much more capablebevy_reflect
crate. It enables you to dynamically interact with Rust types:Why replace bevy_property?
bevy_property
used a lot of invented jargon and was built for a very specific use case.bevy_reflect
is intended to be a "generic" rust reflection cratebevy_property
had a number of limitations in how properties could be accessed (ex: nesting didn't work in some cases)bevy_property
didn't account for traits very well and it wasn't very extensiblebevy_property
used a single trait for all types and overloaded behaviors for things like maps and lists in a way that was confusing at best and in some cases, actively harmfulFeatures
Derive the Reflect traits
Interact with fields using their names
"Patch" your types with new values
Look up nested fields using "path strings"
Iterate over struct fields
Automatically serialize and deserialize via Serde (without explicit serde impls)
Trait "reflection"
Call a trait on a given &dyn Reflect reference without knowing the underlying type!
Why make this?
The whole point of Rust is static safety! Why build something that makes it easy to throw it all away?
Future Work
inventory
crate to remove the need to manually register types. I actually already integrated it, but there were two problems:inventory
(and the general approach it uses) has a show-stopping rustc buginventory
(and the general approach it uses) doesn't support wasm