Skip to content
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

Merged
merged 32 commits into from
Oct 9, 2023
Merged

Conversation

soqb
Copy link
Contributor

@soqb soqb commented Jun 6, 2023

Objective

  • Followup to reflect: stable type path v2 #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 #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 (note that String is in the default Rust prelude) snuck in completely under the radar.

@alice-i-cecile alice-i-cecile added C-Code-Quality A section of code that is hard to understand or change C-Usability A simple quality-of-life change that makes Bevy easier to use A-Reflection Runtime information about types D-Complex Quite challenging from either a design or technical perspective. Ask for help! and removed C-Code-Quality A section of code that is hard to understand or change labels Jun 6, 2023
@alice-i-cecile alice-i-cecile added this to the 0.11 milestone Jun 6, 2023
@alice-i-cecile alice-i-cecile added the A-Assets Load files from disk to use for things like images, models, and sounds label Jun 6, 2023
@MrGVSV MrGVSV self-requested a review June 6, 2023 22:03
@soqb soqb force-pushed the reflect-type-path-part-2 branch from 66d6322 to bd0b407 Compare June 23, 2023 15:30
@soqb
Copy link
Contributor Author

soqb commented Jun 23, 2023

i've stripped down this PR (TypeUuid is no longer deprecated), in the hopes we can squeeze this in before 0.11!

@soqb soqb marked this pull request as ready for review June 23, 2023 15:58
Copy link
Member

@MrGVSV MrGVSV left a 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!

crates/bevy_reflect/src/array.rs Outdated Show resolved Hide resolved
crates/bevy_reflect/src/serde/de.rs Show resolved Hide resolved
crates/bevy_reflect/src/reflect.rs Show resolved Hide resolved
crates/bevy_reflect/src/type_registry.rs Outdated Show resolved Hide resolved
crates/bevy_reflect/src/impls/std.rs Outdated Show resolved Hide resolved
crates/bevy_reflect/src/impls/std.rs Show resolved Hide resolved
crates/bevy_reflect/src/lib.rs Show resolved Hide resolved
crates/bevy_reflect/src/lib.rs Show resolved Hide resolved
crates/bevy_scene/src/serde.rs Show resolved Hide resolved
@soqb
Copy link
Contributor Author

soqb commented Jun 26, 2023

failure in CI fixed by #8957, so that is a prerequisite for this.

@cart cart added this to the 0.12 milestone Jul 7, 2023
@github-actions
Copy link
Contributor

Example alien_cake_addict failed to run, please try running it locally and check the result.

@github-actions
Copy link
Contributor

Example alien_cake_addict failed to run, please try running it locally and check the result.

Copy link
Member

@MrGVSV MrGVSV left a 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!

crates/bevy_reflect/src/lib.rs Show resolved Hide resolved
crates/bevy_reflect/src/lib.rs Show resolved Hide resolved
crates/bevy_reflect/src/impls/std.rs Show resolved Hide resolved
crates/bevy_scene/src/dynamic_scene.rs Show resolved Hide resolved
crates/bevy_scene/src/scene_spawner.rs Show resolved Hide resolved
Copy link
Contributor

@kristoff3r kristoff3r left a 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 -> TypePathTable
  • type_path_vtable -> type_path_table

crates/bevy_reflect/src/serde/ser.rs Show resolved Hide resolved
@alice-i-cecile
Copy link
Member

@MrGVSV, can you go through and resolve conversations that are no longer relevant? @soqb, can you rebase? I think we can get this done for 0.12, so let's get the final steps rolling.

@MrGVSV
Copy link
Member

MrGVSV commented Sep 18, 2023

@MrGVSV, can you go through and resolve conversations that are no longer relevant?

I think this would have to be done by the author or the PR (@soqb).

@soqb
Copy link
Contributor Author

soqb commented Sep 18, 2023

i'll get round to updating everything this week when i get a spot

@@ -146,7 +146,8 @@ impl<B: Bundle + Reflect + FromWorld> FromType<B> for ReflectBundle {
.for_each(|field| insert_field::<B>(entity, field, registry)),
_ => panic!(
"expected bundle `{}` to be named struct or tuple",
std::any::type_name::<B>()
// FIXME: once we have unique reflect, use `TypePath`.
Copy link
Member

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,)*) => {
Copy link
Member

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

Comment on lines -1810 to +1796
a_struct: bevy_reflect::tests::should_reflect_debug::SomeStruct {
a_struct: bevy_reflect::tests::SomeStruct {
Copy link
Member

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.

crates/bevy_reflect/src/reflect.rs Show resolved Hide resolved
@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Sep 29, 2023
@alice-i-cecile
Copy link
Member

@soqb @MrGVSV It looks like there's a bit of cleanup left (and merge conflicts). Do you feel like we should block on that, or just merge this and move on?

@MrGVSV
Copy link
Member

MrGVSV commented Oct 2, 2023

@soqb @MrGVSV It looks like there's a bit of cleanup left (and merge conflicts). Do you feel like we should block on that, or just merge this and move on?

Not sure about the merge conflicts, but I believe my remaining comments are more nits than anything we should block on.

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Oct 9, 2023
Merged via the queue into bevyengine:main with commit 262846e Oct 9, 2023
21 checks passed
@cart cart mentioned this pull request Oct 13, 2023
43 tasks
regnarock pushed a commit to regnarock/bevy that referenced this pull request Oct 13, 2023
# 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.
ameknite pushed a commit to ameknite/bevy that referenced this pull request Nov 6, 2023
# 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.
rdrpenguin04 pushed a commit to rdrpenguin04/bevy that referenced this pull request Jan 9, 2024
# 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Assets Load files from disk to use for things like images, models, and sounds A-Reflection Runtime information about types C-Usability A simple quality-of-life change that makes Bevy easier to use D-Complex Quite challenging from either a design or technical perspective. Ask for help! S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

5 participants