-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Adapt Commands apis for consistency with new World apis #1562
Comments
@cart there's quite a few of us who are enthusiastic about this change, and I think the API consistency is very valuable. Can we add this to the 0.5 milestone? |
Yup I dig it! |
Theres only one mismatch between Commands and World: world.spawn().insert_bundle(SomeBundle { .. });
commands.spawn(SomeBundle { .. }); I'm thinking that moving to I think that consistency is a good idea, but maybe we should pursue alternatives, such as making However there is the matter of |
Currently investigating how disruptive moving to an api that completely mirrors the relevant World functions (including the "type state" pattern). I don't want to rush that in, but its also pretty surface level. I largely want to see how painful it is to adapt the examples. |
Resolves #1253 #1562 This makes the Commands apis consistent with World apis. This moves to a "type state" pattern (like World) where the "current entity" is stored in an `EntityCommands` builder. In general this tends to cuts down on indentation and line count. It comes at the cost of needing to type `commands` more and adding more semicolons to terminate expressions. I also added `spawn_bundle` to Commands because this is a common enough operation that I think its worth providing a shorthand.
Closed by #1703 |
From Future Work of #1525.
The text was updated successfully, but these errors were encountered: