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

Bundles should be unordered #1747

Closed
alice-i-cecile opened this issue Mar 25, 2021 · 1 comment
Closed

Bundles should be unordered #1747

alice-i-cecile opened this issue Mar 25, 2021 · 1 comment
Labels
A-ECS Entities, components, systems, and events C-Code-Quality A section of code that is hard to understand or change C-Feature A new feature, making something new possible

Comments

@alice-i-cecile
Copy link
Member

What problem does this solve or what need does it fill?

Semantically, the ordering of the components in a Bundle shouldn't matter. Components aren't inserted "in order" into our entities and Bundle(A, B) should be identical to Bundle(B, A).

Right now though, they're stored as ordered structs / tuples. This is less than ideal because:

  1. It gives the wrong mental model.
  2. It reduces the ability to batch bundles for command processing.
  3. It makes implementing advanced bundle reliant features like archetype invariants (Archetype Invariants #1481) or kinded entities (Kinded entities #1634) much more cumbersome.

What solution would you like?

Bundles are altered to use an unordered collection representation, directly analogous to a HashSet.

What alternative(s) have you considered?

Implement bundle equality, subsetting etc and other needed features in a manual and indirect fashion, by e.g. comparing the HashSet of the TypeId of their components.

Additional context

Discussed on Discord.

Probably blocked on some Rust RFC that I don't know the name of :(

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Code-Quality A section of code that is hard to understand or change C-Feature A new feature, making something new possible labels Mar 25, 2021
@alice-i-cecile
Copy link
Member Author

From @cart on Discord, the conclusions are:

  1. The misleading mental model isn't great but this can't be fixed without sacrifices.
  2. The methods I really want for archetype invariants etc are actually needed at the archetype level.

Closing this, but feel free to resurrect it if you think of a really clever way to improve the ergonomics.

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-Code-Quality A section of code that is hard to understand or change C-Feature A new feature, making something new possible
Projects
None yet
Development

No branches or pull requests

1 participant