Skip to content

Conversation

@PROMETHIA-27
Copy link
Contributor

@PROMETHIA-27 PROMETHIA-27 commented Apr 19, 2022

Objective

Relevant issue: #4474

Currently glam types implement Reflect as a value, which is problematic for reflection, making scripting/editor work much more difficult. This PR re-implements them as structs.

Solution

Added a new proc macro, impl_reflect_struct, which replaces impl_reflect_value and impl_from_reflect_value for glam types. This macro could also be used for other types, but I don't know of any that would require it. It's specifically useful for foreign types that cannot derive Reflect normally.


Changelog

Added

  • impl_reflect_struct proc macro

Changed

  • Glam reflect impls have been replaced with impl_reflect_struct
  • from_reflect's impl_struct altered to take an optional custom constructor, allowing non-default non-constructible foreign types to use it
  • Calls to impl_struct altered to conform to new signature
  • Altered glam types (All vec/mat combinations) have a different serialization structure, as they are reflected differently now.

Migration Guide

This will break altered glam types serialized to RON scenes, as they will expect to be serialized/deserialized as structs rather than values now. A future PR to add custom serialization for non-value types is likely on the way to restore previous behavior. Additionally, calls to impl_struct must add a None parameter to the end of the call to restore previous behavior.

@github-actions github-actions bot added the S-Needs-Triage This issue needs to be labelled label Apr 19, 2022
@alice-i-cecile alice-i-cecile added A-Reflection Runtime information about types A-Math Fundamental domain-agnostic mathematical operations and removed S-Needs-Triage This issue needs to be labelled labels Apr 19, 2022
To address issues where `use bevy_reflect::Struct` is ambiguous
when called from bevy_reflect
@MrGVSV
Copy link
Member

MrGVSV commented Apr 22, 2022

I could be wrong, but I believe this would break current scene formats which expect a tuple-like value:

{
  "type": "glam::vec3::Vec3",
  "value": (1.0, 1.0, 1.0),
},

This would then become:

{
  "type": "glam::vec3::Vec3",
  "struct": {
    "x": {
      "type": "f32",
      "value": 1.0
    },
    // ...
  },
},

This is probably okay, but worth mentioning in the migration guide at least.

@PROMETHIA-27
Copy link
Contributor Author

That makes sense. I'm having trouble confirming it from looking at bevy_serde, but I will try to test this soon. Will add it to the description.

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.

Overall, I think this is a good change. I was torn at first because I like the one-line tuples defined in the scene format, but I realize now that we can just define custom serde implementations if we really wanted to keep them like that. So I'm on board!

Left a few suggestions and some points for discussion.

One last thing I think this PR really needs is a set of tests. Could you also add some of those?

@PROMETHIA-27
Copy link
Contributor Author

I've verified that this change alters how glam types are serialized like you mentioned. If they're serialized directly, they work as normal (e.g. using serialize_ron() from bevy_scene::dynamic_scene) but when using ReflectSerializer they are unfolded as complex struct definitions. The reflect serializer/deserializer likely only respects custom serializers when that type is a value, not when it's a struct. Not sure where to proceed with that from here; maybe letting struct reflect types check for a custom serialization scheme and use that if present? I feel like that deserves its own PR though.

@MrGVSV
Copy link
Member

MrGVSV commented Apr 23, 2022

The reflect serializer/deserializer likely only respects custom serializers when that type is a value, not when it's a struct. Not sure where to proceed with that from here; maybe letting struct reflect types check for a custom serialization scheme and use that if present? I feel like that deserves its own PR though.

Yep this is currently the case. I addressed this in #4561 to hopefully allow custom implementations to be used. But either way I think you’re okay not worrying about serialization 🙂

@PROMETHIA-27
Copy link
Contributor Author

Nice! I'll keep working on the other suggestions in the meantime then.

@alice-i-cecile alice-i-cecile added the C-Code-Quality A section of code that is hard to understand or change label Apr 25, 2022
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good. One nit about naming conventions; I didn't recognize ctor at a glance.

PROMETHIA-27 and others added 3 commits May 9, 2022 12:11
Co-authored-by: Alice Cecile <[email protected]>
Co-authored-by: Alice Cecile <[email protected]>
Co-authored-by: Alice Cecile <[email protected]>
@alice-i-cecile
Copy link
Member

bors r+

bors bot pushed a commit that referenced this pull request May 9, 2022
#4540)

# Objective

Relevant issue: #4474

Currently glam types implement Reflect as a value, which is problematic for reflection, making scripting/editor work much more difficult. This PR re-implements them as structs.

## Solution

Added a new proc macro, `impl_reflect_struct`, which replaces `impl_reflect_value` and `impl_from_reflect_value` for glam types. This macro could also be used for other types, but I don't know of any that would require it. It's specifically useful for foreign types that cannot derive Reflect normally.

---

## Changelog

### Added
- `impl_reflect_struct` proc macro

### Changed
- Glam reflect impls have been replaced with `impl_reflect_struct`
- from_reflect's `impl_struct` altered to take an optional custom constructor, allowing non-default non-constructible foreign types to use it
- Calls to `impl_struct` altered to conform to new signature
- Altered glam types (All vec/mat combinations) have a different serialization structure, as they are reflected differently now.

## Migration Guide

This will break altered glam types serialized to RON scenes, as they will expect to be serialized/deserialized as structs rather than values now. A future PR to add custom serialization for non-value types is likely on the way to restore previous behavior. Additionally, calls to `impl_struct` must add a `None` parameter to the end of the call to restore previous behavior.

Co-authored-by: PROMETHIA-27 <[email protected]>
@bors bors bot changed the title Add macro to implement reflect for struct types and migrate glam types [Merged by Bors] - Add macro to implement reflect for struct types and migrate glam types May 9, 2022
@bors bors bot closed this May 9, 2022
robtfm pushed a commit to robtfm/bevy that referenced this pull request May 10, 2022
bevyengine#4540)

# Objective

Relevant issue: bevyengine#4474

Currently glam types implement Reflect as a value, which is problematic for reflection, making scripting/editor work much more difficult. This PR re-implements them as structs.

## Solution

Added a new proc macro, `impl_reflect_struct`, which replaces `impl_reflect_value` and `impl_from_reflect_value` for glam types. This macro could also be used for other types, but I don't know of any that would require it. It's specifically useful for foreign types that cannot derive Reflect normally.

---

## Changelog

### Added
- `impl_reflect_struct` proc macro

### Changed
- Glam reflect impls have been replaced with `impl_reflect_struct`
- from_reflect's `impl_struct` altered to take an optional custom constructor, allowing non-default non-constructible foreign types to use it
- Calls to `impl_struct` altered to conform to new signature
- Altered glam types (All vec/mat combinations) have a different serialization structure, as they are reflected differently now.

## Migration Guide

This will break altered glam types serialized to RON scenes, as they will expect to be serialized/deserialized as structs rather than values now. A future PR to add custom serialization for non-value types is likely on the way to restore previous behavior. Additionally, calls to `impl_struct` must add a `None` parameter to the end of the call to restore previous behavior.

Co-authored-by: PROMETHIA-27 <[email protected]>
exjam pushed a commit to exjam/bevy that referenced this pull request May 22, 2022
bevyengine#4540)

# Objective

Relevant issue: bevyengine#4474

Currently glam types implement Reflect as a value, which is problematic for reflection, making scripting/editor work much more difficult. This PR re-implements them as structs.

## Solution

Added a new proc macro, `impl_reflect_struct`, which replaces `impl_reflect_value` and `impl_from_reflect_value` for glam types. This macro could also be used for other types, but I don't know of any that would require it. It's specifically useful for foreign types that cannot derive Reflect normally.

---

## Changelog

### Added
- `impl_reflect_struct` proc macro

### Changed
- Glam reflect impls have been replaced with `impl_reflect_struct`
- from_reflect's `impl_struct` altered to take an optional custom constructor, allowing non-default non-constructible foreign types to use it
- Calls to `impl_struct` altered to conform to new signature
- Altered glam types (All vec/mat combinations) have a different serialization structure, as they are reflected differently now.

## Migration Guide

This will break altered glam types serialized to RON scenes, as they will expect to be serialized/deserialized as structs rather than values now. A future PR to add custom serialization for non-value types is likely on the way to restore previous behavior. Additionally, calls to `impl_struct` must add a `None` parameter to the end of the call to restore previous behavior.

Co-authored-by: PROMETHIA-27 <[email protected]>
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
bevyengine#4540)

# Objective

Relevant issue: bevyengine#4474

Currently glam types implement Reflect as a value, which is problematic for reflection, making scripting/editor work much more difficult. This PR re-implements them as structs.

## Solution

Added a new proc macro, `impl_reflect_struct`, which replaces `impl_reflect_value` and `impl_from_reflect_value` for glam types. This macro could also be used for other types, but I don't know of any that would require it. It's specifically useful for foreign types that cannot derive Reflect normally.

---

## Changelog

### Added
- `impl_reflect_struct` proc macro

### Changed
- Glam reflect impls have been replaced with `impl_reflect_struct`
- from_reflect's `impl_struct` altered to take an optional custom constructor, allowing non-default non-constructible foreign types to use it
- Calls to `impl_struct` altered to conform to new signature
- Altered glam types (All vec/mat combinations) have a different serialization structure, as they are reflected differently now.

## Migration Guide

This will break altered glam types serialized to RON scenes, as they will expect to be serialized/deserialized as structs rather than values now. A future PR to add custom serialization for non-value types is likely on the way to restore previous behavior. Additionally, calls to `impl_struct` must add a `None` parameter to the end of the call to restore previous behavior.

Co-authored-by: PROMETHIA-27 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Math Fundamental domain-agnostic mathematical operations A-Reflection Runtime information about types C-Code-Quality A section of code that is hard to understand or change

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants