-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
reflect: TypePath part 2
#8768
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
reflect: TypePath part 2
#8768
Conversation
66d6322 to
bd0b407
Compare
|
i've stripped down this PR ( |
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.
Looking great! And yeah removing the TypeUuid changes definitely helped make this review a bit nicer.
Just some comments, questions, and nitpicks!
|
failure in CI fixed by #8957, so that is a prerequisite for this. |
|
Example |
|
Example |
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.
Looks good to me!
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 read through everything and it looks very reasonable to me (although I'm completely new to bevy_reflect so take that with a grain of salt). All the changed code looks the same or better.
Also the link to the "incorrect type path implementation" is dead, it would've been nice to know what that was so I could have looked for similar stuff or missing tests.
There were some names in the changelog that hasn't been updated to match the code:
TypePathVtable->TypePathTabletype_path_vtable->type_path_table
|
i'll get round to updating everything this week when i get a spot |
| _ => panic!( | ||
| "expected bundle `{}` to be named struct or tuple", | ||
| std::any::type_name::<B>() | ||
| // FIXME: once we have unique reflect, use `TypePath`. |
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.
Nit: Could you add an issue link to these FIXME comments?
| } | ||
|
|
||
| macro_rules! assert_type_paths { | ||
| ($($ty:ty => $long:literal, $short:literal,)*) => { |
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.
Total nitpick that definitely is not required: I think wrapping the literals in parentheses (like a tuple) might be easier to read, but that's definitely just my opinion haha
| a_struct: bevy_reflect::tests::should_reflect_debug::SomeStruct { | ||
| a_struct: bevy_reflect::tests::SomeStruct { |
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.
Hm, does TypePath mention this quirk (due to module_path!)? If not, that might be worth adding as part of this PR so users who are defining structs inside functions aren't wholly caught off guard.
…t-type-path-part-2
# Objective - Followup to bevyengine#7184. - ~Deprecate `TypeUuid` and remove its internal references.~ No longer part of this PR. - Use `TypePath` for the type registry, and (de)serialisation instead of `std::any::type_name`. - Allow accessing type path information behind proxies. ## Solution - Introduce methods on `TypeInfo` and friends for dynamically querying type path. These methods supersede the old `type_name` methods. - Remove `Reflect::type_name` in favor of `DynamicTypePath::type_path` and `TypeInfo::type_path_table`. - Switch all uses of `std::any::type_name` in reflection, non-debugging contexts to use `TypePath`. --- ## Changelog - Added `TypePathTable` for dynamically accessing methods on `TypePath` through `TypeInfo` and the type registry. - Removed `type_name` from all `TypeInfo`-like structs. - Added `type_path` and `type_path_table` methods to all `TypeInfo`-like structs. - Removed `Reflect::type_name` in favor of `DynamicTypePath::reflect_type_path` and `TypeInfo::type_path`. - Changed the signature of all `DynamicTypePath` methods to return strings with a static lifetime. ## Migration Guide - Rely on `TypePath` instead of `std::any::type_name` for all stability guarantees and for use in all reflection contexts, this is used through with one of the following APIs: - `TypePath::type_path` if you have a concrete type and not a value. - `DynamicTypePath::reflect_type_path` if you have an `dyn Reflect` value without a concrete type. - `TypeInfo::type_path` for use through the registry or if you want to work with the represented type of a `DynamicFoo`. - Remove `type_name` from manual `Reflect` implementations. - Use `type_path` and `type_path_table` in place of `type_name` on `TypeInfo`-like structs. - Use `get_with_type_path(_mut)` over `get_with_type_name(_mut)`. ## Note to reviewers I think if anything we were a little overzealous in merging bevyengine#7184 and we should take that extra care here. In my mind, this is the "point of no return" for `TypePath` and while I think we all agree on the design, we should carefully consider if the finer details and current implementations are actually how we want them moving forward. For example [this incorrect `TypePath` implementation for `String`](https://github.com/soqb/bevy/blob/3fea3c6c0b5719dfbd3d4230f5282ec80d82556a/crates/bevy_reflect/src/impls/std.rs#L90) (note that `String` is in the default Rust prelude) snuck in completely under the radar.
# Objective - Followup to bevyengine#7184. - ~Deprecate `TypeUuid` and remove its internal references.~ No longer part of this PR. - Use `TypePath` for the type registry, and (de)serialisation instead of `std::any::type_name`. - Allow accessing type path information behind proxies. ## Solution - Introduce methods on `TypeInfo` and friends for dynamically querying type path. These methods supersede the old `type_name` methods. - Remove `Reflect::type_name` in favor of `DynamicTypePath::type_path` and `TypeInfo::type_path_table`. - Switch all uses of `std::any::type_name` in reflection, non-debugging contexts to use `TypePath`. --- ## Changelog - Added `TypePathTable` for dynamically accessing methods on `TypePath` through `TypeInfo` and the type registry. - Removed `type_name` from all `TypeInfo`-like structs. - Added `type_path` and `type_path_table` methods to all `TypeInfo`-like structs. - Removed `Reflect::type_name` in favor of `DynamicTypePath::reflect_type_path` and `TypeInfo::type_path`. - Changed the signature of all `DynamicTypePath` methods to return strings with a static lifetime. ## Migration Guide - Rely on `TypePath` instead of `std::any::type_name` for all stability guarantees and for use in all reflection contexts, this is used through with one of the following APIs: - `TypePath::type_path` if you have a concrete type and not a value. - `DynamicTypePath::reflect_type_path` if you have an `dyn Reflect` value without a concrete type. - `TypeInfo::type_path` for use through the registry or if you want to work with the represented type of a `DynamicFoo`. - Remove `type_name` from manual `Reflect` implementations. - Use `type_path` and `type_path_table` in place of `type_name` on `TypeInfo`-like structs. - Use `get_with_type_path(_mut)` over `get_with_type_name(_mut)`. ## Note to reviewers I think if anything we were a little overzealous in merging bevyengine#7184 and we should take that extra care here. In my mind, this is the "point of no return" for `TypePath` and while I think we all agree on the design, we should carefully consider if the finer details and current implementations are actually how we want them moving forward. For example [this incorrect `TypePath` implementation for `String`](https://github.com/soqb/bevy/blob/3fea3c6c0b5719dfbd3d4230f5282ec80d82556a/crates/bevy_reflect/src/impls/std.rs#L90) (note that `String` is in the default Rust prelude) snuck in completely under the radar.
# Objective - Followup to bevyengine#7184. - ~Deprecate `TypeUuid` and remove its internal references.~ No longer part of this PR. - Use `TypePath` for the type registry, and (de)serialisation instead of `std::any::type_name`. - Allow accessing type path information behind proxies. ## Solution - Introduce methods on `TypeInfo` and friends for dynamically querying type path. These methods supersede the old `type_name` methods. - Remove `Reflect::type_name` in favor of `DynamicTypePath::type_path` and `TypeInfo::type_path_table`. - Switch all uses of `std::any::type_name` in reflection, non-debugging contexts to use `TypePath`. --- ## Changelog - Added `TypePathTable` for dynamically accessing methods on `TypePath` through `TypeInfo` and the type registry. - Removed `type_name` from all `TypeInfo`-like structs. - Added `type_path` and `type_path_table` methods to all `TypeInfo`-like structs. - Removed `Reflect::type_name` in favor of `DynamicTypePath::reflect_type_path` and `TypeInfo::type_path`. - Changed the signature of all `DynamicTypePath` methods to return strings with a static lifetime. ## Migration Guide - Rely on `TypePath` instead of `std::any::type_name` for all stability guarantees and for use in all reflection contexts, this is used through with one of the following APIs: - `TypePath::type_path` if you have a concrete type and not a value. - `DynamicTypePath::reflect_type_path` if you have an `dyn Reflect` value without a concrete type. - `TypeInfo::type_path` for use through the registry or if you want to work with the represented type of a `DynamicFoo`. - Remove `type_name` from manual `Reflect` implementations. - Use `type_path` and `type_path_table` in place of `type_name` on `TypeInfo`-like structs. - Use `get_with_type_path(_mut)` over `get_with_type_name(_mut)`. ## Note to reviewers I think if anything we were a little overzealous in merging bevyengine#7184 and we should take that extra care here. In my mind, this is the "point of no return" for `TypePath` and while I think we all agree on the design, we should carefully consider if the finer details and current implementations are actually how we want them moving forward. For example [this incorrect `TypePath` implementation for `String`](https://github.com/soqb/bevy/blob/3fea3c6c0b5719dfbd3d4230f5282ec80d82556a/crates/bevy_reflect/src/impls/std.rs#L90) (note that `String` is in the default Rust prelude) snuck in completely under the radar.
Objective
DeprecateNo longer part of this PR.TypeUuidand remove its internal references.TypePathfor the type registry, and (de)serialisation instead ofstd::any::type_name.Solution
TypeInfoand friends for dynamically querying type path. These methods supersede the oldtype_namemethods.Reflect::type_namein favor ofDynamicTypePath::type_pathandTypeInfo::type_path_table.std::any::type_namein reflection, non-debugging contexts to useTypePath.Changelog
TypePathTablefor dynamically accessing methods onTypePaththroughTypeInfoand the type registry.type_namefrom allTypeInfo-like structs.type_pathandtype_path_tablemethods to allTypeInfo-like structs.Reflect::type_namein favor ofDynamicTypePath::reflect_type_pathandTypeInfo::type_path.DynamicTypePathmethods to return strings with a static lifetime.Migration Guide
Rely on
TypePathinstead ofstd::any::type_namefor all stability guarantees and for use in all reflection contexts, this is used through with one of the following APIs:TypePath::type_pathif you have a concrete type and not a value.DynamicTypePath::reflect_type_pathif you have andyn Reflectvalue without a concrete type.TypeInfo::type_pathfor use through the registry or if you want to work with the represented type of aDynamicFoo.Remove
type_namefrom manualReflectimplementations.Use
type_pathandtype_path_tablein place oftype_nameonTypeInfo-like structs.Use
get_with_type_path(_mut)overget_with_type_name(_mut).Note to reviewers
I think if anything we were a little overzealous in merging #7184 and we should take that extra care here.
In my mind, this is the "point of no return" for
TypePathand while I think we all agree on the design, we should carefully consider if the finer details and current implementations are actually how we want them moving forward.For example this incorrect
TypePathimplementation forString(note thatStringis in the default Rust prelude) snuck in completely under the radar.