Skip to content

Conversation

@Bleachfuel
Copy link
Contributor

@Bleachfuel Bleachfuel commented Feb 17, 2025

Objective

fixes #17896

Solution

Change ChildOf ( Entity ) to ChildOf { parent: Entity }

by doing this we also allow users to use named structs for relationship derives, When you have more than 1 field in a struct with named fields the macro will look for a field with the attribute #[relationship] and all of the other fields should implement the Default trait. Unnamed fields are still supported.

When u have a unnamed struct with more than one field the macro will fail.
Do we want to support something like this ?

 #[derive(Component)]
 #[relationship_target(relationship = ChildOf)]
 pub struct Children (#[relationship] Entity, u8);

I could add this, it but doesn't seem nice.

Testing

crates/bevy_ecs - cargo test

Showcase

use bevy_ecs::component::Component;
use bevy_ecs::entity::Entity;

 #[derive(Component)]
 #[relationship(relationship_target = Children)]
 pub struct ChildOf {
     #[relationship]
     pub parent: Entity,
     internal: u8,
 };

 #[derive(Component)]
 #[relationship_target(relationship = ChildOf)]
 pub struct Children {
     children: Vec<Entity>
 };

@Bleachfuel Bleachfuel changed the title support named struct Relationship types Add support for deriving Relationship and RelationshipTarget with named structs Feb 18, 2025
@Bleachfuel Bleachfuel force-pushed the main branch 2 times, most recently from 589c7cc to 2fe51a0 Compare February 19, 2025 17:48
@Bleachfuel Bleachfuel changed the title Add support for deriving Relationship and RelationshipTarget with named structs Change ChildOf to Childof { parent: Entity} and support deriving Relationship and RelationshipTarget with named structs Feb 19, 2025
@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use X-Blessed Has a large architectural impact or tradeoffs, but the design has been endorsed by decision makers labels Feb 23, 2025
@alice-i-cecile alice-i-cecile added this to the 0.16 milestone Feb 23, 2025
@alice-i-cecile alice-i-cecile added the S-Needs-Review Needs reviewer attention (from anyone!) to move forward label Feb 23, 2025
@alice-i-cecile alice-i-cecile requested a review from cart February 25, 2025 23:35
@alice-i-cecile
Copy link
Member

When u have a unnamed struct with more than one field the macro will fail.
Do we want to support something like this ?

No, that's unpleasant, and trivially worked around.

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.

Nice work :) Thanks a ton for finishing this up; you're much more adept with the macros than I am!

Tim Overbeek and others added 2 commits February 26, 2025 01:42
Copy link
Member

@cart cart left a comment

Choose a reason for hiding this comment

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

Well done! Thanks for putting this together!

@cart cart added this pull request to the merge queue Feb 27, 2025
Merged via the queue into bevyengine:main with commit ccb7069 Feb 27, 2025
30 checks passed
greeble-dev added a commit to greeble-dev/bevy that referenced this pull request Feb 27, 2025
github-merge-queue bot pushed a commit that referenced this pull request Feb 28, 2025
#17905 replaced `ChildOf(entity)`
with `ChildOf { parent: entity }`, but some deprecation advice was
overlooked. Also corrected formatting in documentation.

## Testing

Added a `set_parent` to a random example. Confirmed that the deprecation
warning shows and the advice can be pasted in.
github-merge-queue bot pushed a commit that referenced this pull request Apr 2, 2025
# Objective

In #17905 we swapped to a named field on `ChildOf` to help resolve
variable naming ambiguity of child vs parent (ex: `child_of.parent`
clearly reads as "I am accessing the parent of the child_of
relationship", whereas `child_of.0` is less clear).

Unfortunately this has the side effect of making initialization less
ideal. `ChildOf { parent }` reads just as well as `ChildOf(parent)`, but
`ChildOf { parent: root }` doesn't read nearly as well as
`ChildOf(root)`.

## Solution

Move back to `ChildOf(pub Entity)` but add a `child_of.parent()`
function and use it for all accesses. The downside here is that users
are no longer "forced" to access the parent field with `parent`
nomenclature, but I think this strikes the right balance.

Take a look at the diff. I think the results provide strong evidence for
this change. Initialization has the benefit of reading much better _and_
of taking up significantly less space, as many lines go from 3 to 1, and
we're cutting out a bunch of syntax in some cases.

Sadly I do think this should land in 0.16 as the cost of doing this
_after_ the relationships migration is high.
mockersf pushed a commit that referenced this pull request Apr 3, 2025
# Objective

In #17905 we swapped to a named field on `ChildOf` to help resolve
variable naming ambiguity of child vs parent (ex: `child_of.parent`
clearly reads as "I am accessing the parent of the child_of
relationship", whereas `child_of.0` is less clear).

Unfortunately this has the side effect of making initialization less
ideal. `ChildOf { parent }` reads just as well as `ChildOf(parent)`, but
`ChildOf { parent: root }` doesn't read nearly as well as
`ChildOf(root)`.

## Solution

Move back to `ChildOf(pub Entity)` but add a `child_of.parent()`
function and use it for all accesses. The downside here is that users
are no longer "forced" to access the parent field with `parent`
nomenclature, but I think this strikes the right balance.

Take a look at the diff. I think the results provide strong evidence for
this change. Initialization has the benefit of reading much better _and_
of taking up significantly less space, as many lines go from 3 to 1, and
we're cutting out a bunch of syntax in some cases.

Sadly I do think this should land in 0.16 as the cost of doing this
_after_ the relationships migration is high.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Needs-Review Needs reviewer attention (from anyone!) to move forward X-Blessed Has a large architectural impact or tradeoffs, but the design has been endorsed by decision makers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make ChildOf a named struct and support named struct Relationship types

3 participants