Skip to content

Conversation

alice-i-cecile
Copy link
Member

@alice-i-cecile alice-i-cecile commented Mar 10, 2022

Objective

  • Hierarchy tools are not just used for Transform: they are also used for scenes.
  • In the future there's interest in using them for other features, such as visiibility inheritance.
  • The fact that these tools are found in bevy_transform causes a great deal of user and developer confusion
  • Fixes Should bevy-transform be two crates? #2758.

Solution

  • Split bevy_transform into two!
  • Make everything work again.

Note that this is a very tightly scoped PR: I know there are code quality and docs issues that existed in bevy_transform that I've just moved around. We should fix those in a seperate PR and try to merge this ASAP to reduce the bitrot involved in splitting an entire crate.

Frustrations

The API around GlobalTransform is a mess: we have massive code and docs duplication, no link between the two types and no clear way to extend this to other forms of inheritance.

In the medium-term, I feel pretty strongly that GlobalTransform should be replaced by something like Inherited<Transform>, which lives in bevy_hierarchy:

  • avoids code duplication
  • makes the inheritance pattern extensible
  • links the types at the type-level
  • allows us to remove all references to inheritance from bevy_transform, making it more useful as a standalone crate and cleaning up its docs

Additional context

@github-actions github-actions bot added the S-Needs-Triage This issue needs to be labelled label Mar 10, 2022
@alice-i-cecile
Copy link
Member Author

@cart as part of this PR's merge process, can we get a A - Hierarchy label?

@alice-i-cecile alice-i-cecile added A-Transform Translations, rotations and scales C-Code-Quality A section of code that is hard to understand or change and removed S-Needs-Triage This issue needs to be labelled labels Mar 10, 2022
@alice-i-cecile
Copy link
Member Author

bors try

bors bot added a commit that referenced this pull request Mar 12, 2022
@bors
Copy link
Contributor

bors bot commented Mar 12, 2022

try

Build failed:

@IceSentry
Copy link
Contributor

IceSentry commented Mar 12, 2022

btw, bevy_hierarchy is not reserved on crates.io. Even if this PR doesn't get merged, we should probably reserve it.

https://crates.io/crates/bevy_hierarchy

I made a PR for that bevyengine/bevy-crate-reservations#15

@mockersf mockersf 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 Mar 14, 2022
@cart
Copy link
Member

cart commented Mar 15, 2022

The API around GlobalTransform is a mess: we have massive code and docs duplication, no link between the two types and no clear way to extend this to other forms of inheritance. In the medium-term, I feel pretty strongly that GlobalTransform should be replaced by something like Inherited, which lives in bevy_hierarchy

I object to the framing that a fully separate GlobalTransform component is a "mess". I personally think a named (and fully separate) GlobalTransform type is preferable to a more abstracted "component inheritance system". GlobalTransform having a separate type (and name) makes the context and "space" (as in "world space") of the component clear. It also leaves the door open to things like "adding a GlobalTransform::ignore_parent field".

On the other hand, Inherited<Transform> could literally mean anything (and would mean different things, depending on the context of Inherited + ComponentType). Of course, the value of this design is up for debate (and should be discussed in a different place), but by including "highly opinionated and negatively weighted" thoughts on what we already have, I feel compelled to reply here.

@cart
Copy link
Member

cart commented Mar 15, 2022

(but I do agree that it would be nice to cut down on code duplication ... impl macros or Deref are also options)

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.

Looks good to me. Just one baby nit.

@cart
Copy link
Member

cart commented Mar 15, 2022

bors r+

bors bot pushed a commit that referenced this pull request Mar 15, 2022
# Objective

- Hierarchy tools are not just used for `Transform`: they are also used for scenes.
- In the future there's interest in using them for other features, such as visiibility inheritance.
- The fact that these tools are found in `bevy_transform` causes a great deal of user and developer confusion
- Fixes #2758.

## Solution

- Split `bevy_transform` into two!
- Make everything work again.

Note that this is a very tightly scoped PR: I *know* there are code quality and docs issues that existed in bevy_transform that I've just moved around. We should fix those in a seperate PR and try to merge this ASAP to reduce the bitrot involved in splitting an entire crate.

## Frustrations

The API around `GlobalTransform` is a mess: we have massive code and docs duplication, no link between the two types and no clear way to extend this to other forms of inheritance.

In the medium-term, I feel pretty strongly that `GlobalTransform` should be replaced by something like `Inherited<Transform>`, which lives in `bevy_hierarchy`:

- avoids code duplication
- makes the inheritance pattern extensible
- links the types at the type-level
- allows us to remove all references to inheritance from `bevy_transform`, making it more useful as a standalone crate and cleaning up its docs

## Additional context

- double-blessed by @cart in #4141 (comment) and #2758 (comment)
- preparation for more advanced / cleaner hierarchy tools: go read bevyengine/rfcs#53 !
- originally attempted by @finegeometer in #2789. It was a great idea, just needed more discussion!

Co-authored-by: Carter Anderson <[email protected]>
@alice-i-cecile
Copy link
Member Author

but by including "highly opinionated and negatively weighted" thoughts on what we already have, I feel compelled to reply here.

Fair; this wasn't really the place or tone for it. I'm sorry for that @cart. I was frustrated about the code duplication, but we can debate the relative merits of that design somewhere else.

@bors bors bot changed the title Split bevy_hierarchy out from bevy_transform [Merged by Bors] - Split bevy_hierarchy out from bevy_transform Mar 15, 2022
@bors bors bot closed this Mar 15, 2022
@cart
Copy link
Member

cart commented Mar 15, 2022

Fair; this wasn't really the place or tone for it. I'm sorry for that @cart. I was frustrated about the code duplication, but we can debate the relative merits of that design somewhere else.

No worries. I almost didn't say anything because its definitely ok to think something is a mess (although I try to avoid using that language to avoid hurting peoples' feelings ... and to account for the fact that I might find out I'm wrong about that assessment. When trying to get that point across, I think its better to just outline the specific facts of the situation rather than ascribe generic negative labels to things). I mainly brought it up because I'd rather leave "opinionated discussions and pronouncements about the value of a thing" to issues scoped to that topic. I selfishly don't want to defend my design choices in 10 different places :)

aevyrie pushed a commit to aevyrie/bevy that referenced this pull request Jun 7, 2022
# Objective

- Hierarchy tools are not just used for `Transform`: they are also used for scenes.
- In the future there's interest in using them for other features, such as visiibility inheritance.
- The fact that these tools are found in `bevy_transform` causes a great deal of user and developer confusion
- Fixes bevyengine#2758.

## Solution

- Split `bevy_transform` into two!
- Make everything work again.

Note that this is a very tightly scoped PR: I *know* there are code quality and docs issues that existed in bevy_transform that I've just moved around. We should fix those in a seperate PR and try to merge this ASAP to reduce the bitrot involved in splitting an entire crate.

## Frustrations

The API around `GlobalTransform` is a mess: we have massive code and docs duplication, no link between the two types and no clear way to extend this to other forms of inheritance.

In the medium-term, I feel pretty strongly that `GlobalTransform` should be replaced by something like `Inherited<Transform>`, which lives in `bevy_hierarchy`:

- avoids code duplication
- makes the inheritance pattern extensible
- links the types at the type-level
- allows us to remove all references to inheritance from `bevy_transform`, making it more useful as a standalone crate and cleaning up its docs

## Additional context

- double-blessed by @cart in bevyengine#4141 (comment) and bevyengine#2758 (comment)
- preparation for more advanced / cleaner hierarchy tools: go read bevyengine/rfcs#53 !
- originally attempted by @finegeometer in bevyengine#2789. It was a great idea, just needed more discussion!

Co-authored-by: Carter Anderson <[email protected]>
zkat added a commit to zkat/big-brain that referenced this pull request Sep 24, 2022
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
# Objective

- Hierarchy tools are not just used for `Transform`: they are also used for scenes.
- In the future there's interest in using them for other features, such as visiibility inheritance.
- The fact that these tools are found in `bevy_transform` causes a great deal of user and developer confusion
- Fixes bevyengine#2758.

## Solution

- Split `bevy_transform` into two!
- Make everything work again.

Note that this is a very tightly scoped PR: I *know* there are code quality and docs issues that existed in bevy_transform that I've just moved around. We should fix those in a seperate PR and try to merge this ASAP to reduce the bitrot involved in splitting an entire crate.

## Frustrations

The API around `GlobalTransform` is a mess: we have massive code and docs duplication, no link between the two types and no clear way to extend this to other forms of inheritance.

In the medium-term, I feel pretty strongly that `GlobalTransform` should be replaced by something like `Inherited<Transform>`, which lives in `bevy_hierarchy`:

- avoids code duplication
- makes the inheritance pattern extensible
- links the types at the type-level
- allows us to remove all references to inheritance from `bevy_transform`, making it more useful as a standalone crate and cleaning up its docs

## Additional context

- double-blessed by @cart in bevyengine#4141 (comment) and bevyengine#2758 (comment)
- preparation for more advanced / cleaner hierarchy tools: go read bevyengine/rfcs#53 !
- originally attempted by @finegeometer in bevyengine#2789. It was a great idea, just needed more discussion!

Co-authored-by: Carter Anderson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Transform Translations, rotations and scales C-Code-Quality A section of code that is hard to understand or change S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Should bevy-transform be two crates?
5 participants