Automatically label systems with their TypeId #4219
Labels
A-ECS
Entities, components, systems, and events
C-Usability
A targeted quality-of-life change that makes Bevy easier to use
Comments
alice-i-cecile
added
A-ECS
aevyrie
pushed a commit
to aevyrie/bevy
that referenced
this issue
Jun 7, 2022
This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default.
This enables the following patterns:
```rust
// ordering two systems without manually defining labels
app
.add_system(update_velocity)
.add_system(movement.after(update_velocity))
// ordering sets of systems without manually defining labels
app
.add_system(foo)
.add_system_set(
SystemSet::new()
.after(foo)
.with_system(bar)
.with_system(baz)
)
```
Fixes: bevyengine#4219
Related to: bevyengine#4220
Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
This adds the concept of "default labels" for systems (currently scoped to "parallel systems", but this could just as easily be implemented for "exclusive systems"). Function systems now include their function's `SystemTypeIdLabel` by default.
This enables the following patterns:
```rust
// ordering two systems without manually defining labels
app
.add_system(update_velocity)
.add_system(movement.after(update_velocity))
// ordering sets of systems without manually defining labels
app
.add_system(foo)
.add_system_set(
SystemSet::new()
.after(foo)
.with_system(bar)
.with_system(baz)
)
```
Fixes: bevyengine#4219
Related to: bevyengine#4220
Credit to @aevyrie @alice-i-cecile @DJMcNab (and probably others) for proposing (and supporting) this idea about a year ago. I was a big dummy that both shut down this (very good) idea and then forgot I did that. Sorry. You all were right!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem does this solve or what need does it fill?
In many simple system ordering use cases, users are forced to define simple labels for each system they want to order, creating tedious and duplicative boilerplate, and encouraging the use of stringly-typed system labels.
This is particularly true in applications, rather than plugin libraries, where exposing a clean forwards-compatible public API is of much lower concern.
What solution would you like?
Automatically give each system a
SystemLabelcorresponding to theirTypeId.Change the signature of
.beforeand.afterto accept aimpl IntoSystemLabelargument, and then convert provided system-like functions into the correspondingTypeId, which is then used in schedule graph construction.What alternative(s) have you considered?
We could use the type_name instead of the
TypeIdto define the label. The pros and cons aren't fully clear to me, but the type_name docs state that it should really only be used for diagnostic purposes.IMO we should remove string system labels as part of this change: the "quick-and-dirty" approach is already covered well by this design.
Additional context
The text was updated successfully, but these errors were encountered: