bevy_reflect: Add ReflectFromReflect

[MrGVSV]

Objective

FromReflect requires a concrete type in order for it to be invoked:

let foo = <MyStruct as FromReflect>::from_reflect(&my_dyn_struct).unwrap();

However, we might not always have access to the concrete type. One area this comes up is in deserialization of trait objects. If we have a something like:

#[derive(Reflect, FromReflect)]
#[reflect(MyTrait)]
struct MyStruct {
  foo: i32
}

And some serialized data:

(
  "type": "MyStruct",
  "struct": {
    "foo": {
      "type": "i32",
      "value": 123
    }
  }
)

How do we deserialize this into something like &dyn MyTrait? (or Box<dyn MyTrait> if #4120 gets merged.)

The ReflectDeserializer gives us a Box<dyn Reflect> over a DynamicStruct, but now we need to convert that DynamicStruct to the actual type. We technically know the type— we can get its registration and type information easily. But how do we go about the conversion?

The only way to convert a DynamicStruct to its underlying type (as far as I'm aware) is by using FromReflect. If all we have is the TypeId of the data or its type name, then we can't do much about this.

I believe bevy_scene solves this problem for deserializing scene components by just iterating through the registered components (more-or-less).

Solution

To use FromReflect dynamically, I added a ReflectFromReflect struct (its naming follows the convention of those generated by the #[reflect_trait] macro). This struct contains a method for converting a Dynamic*** object to a reflected concrete one (as a Box<dyn Reflect>). This allows us to deserialize our MyStruct into a &dyn MyTrait like:

let rfr: &ReflectFromReflect = registry
  .get_type_data::<ReflectFromReflect>(type_id)
  .unwrap();

let reflected: Box<dyn Reflect> = rfr
  .from_reflect(&my_dynamic_struct)
  .unwrap();

let my_trait: &ReflectMyTrait = registry
  .get_type_data::<ReflectMyTrait>(type_id)
  .unwrap();

let my_trait_obj: &dyn MyTrait = my_trait
  .get(reflected.as_ref())
  .unwrap();

Limitations

Like other Reflect*** type data, you need to specify its existence using the #[reflect(...)] attribute. This means that any time you derive FromReflect, you'll want to specify that trait as well.

#[derive(Reflect, FromReflect)]
#[reflect(MyTrait, FromReflect)]
struct MyStruct {
  foo: i32
}

This is an annoying quirk that I'm not too sure how to solve since it's not guaranteed that all Reflect types implement FromReflect (see this comment). In other words, we can't just have it always registered in the Reflect derive macro.

This limitation might be too inconvenient, annoying, and/or confusing. If it is, this PR will probably need to be closed until a different solution is found.

Usefulness

In most cases when deserializing, we probably don't need this since we typically have access to the actual type. The biggest use case for this is supporting deserialization of trait objects. However, this can also be useful outside of just handling deserialization, such as for scenarios when only the DynamicStruct is given and a method needs to be called on it.

[MrGVSV]

I’m currently feeling iffy about this. Mainly because:

• It adds boilerplate/confusion
• It's really only useful for trait objects
• We don't even deserialize to the actual type with our current deserializer (just a reflected Dynamic***)

So I’m leaning towards closing this in favor of finding a better solution. But if anyone disagrees or thinks this could be useful, I'll keep it open.

[alice-i-cecile]

@MrGVSV can you make an issue that links to this PR about the challenges we run into working with trait objects? Once that's done, I think we can close this out and revive it later.