-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Description
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?
app.add_system(gravity).add_system(kinematics.after(gravity))Automatically give each system a SystemLabel corresponding to their TypeId.
Change the signature of .before and .after to accept a impl IntoSystemLabel argument, and then convert provided system-like functions into the corresponding TypeId, which is then used in schedule graph construction.
What alternative(s) have you considered?
We could use the type_name instead of the TypeId to 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
I think it would be interesting to consider "automatically labeling" systems with either their type_name or their TypeId