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

[Merged by Bors] - Make Commands and World apis consistent #1703

Closed
wants to merge 6 commits into from

Conversation

cart
Copy link
Member

@cart cart commented Mar 20, 2021

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.

@cart cart added the A-ECS Entities, components, systems, and events label Mar 20, 2021
@cart
Copy link
Member Author

cart commented Mar 20, 2021

This is a pretty big change to user facing apis, so please weigh in if you have alternative ideas. I'd like to avoid touching these any more than we need to.

@alice-i-cecile
Copy link
Member

alice-i-cecile commented Mar 20, 2021

User-facing changes to Commands, collected for your convenience:

  • spawn: no longer takes a bundle. Now much easier to spawn entities with zero / one component.
  • spawn_bundle: new convenience method to get back old behavior.
  • entity: Does... something? It's not documented, but I think it sets the current entity to use with the various EntityCommands
  • id: Seems to be the new replacement for current_entity?
  • add: replaces add_command
  • insert_bundle: replaces with_bundle
  • insert: replaces with
  • current_entity / with_current_entity: removed
  • insert / remove / despawn / various parent-child commands: now use commands.entity(entity).remove()

@alice-i-cecile
Copy link
Member

Now, thoughts. I love these changes. The API is much clearer, more consistent and more explicit, without making anything significantly harder to do.

The previous API often worked in... difficult to grasp and challenging to intuit ways as soon as you stepped beyond copying directly from the examples. The new EntityCommands seems much nicer to write custom commands for.

This API also seems like an excellent step towards batching commands due to the increased explicitness and clarity.

IMO these are the right changes to make, and I'd much rather break things all at once and earlier than do it later. The consistency with World in particular is really valuable for reducing mental overhead for intermediate and advanced users.

})
.with_bundle(SpriteBundle {
let e = commands
.spawn_bundle((
Copy link
Member

@alice-i-cecile alice-i-cecile Mar 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is much nicer to read if you use .spawn().insert_bundle().insert_bundle().

@alice-i-cecile
Copy link
Member

Is it worth solving #792 quickly before 0.5 to make this API really ergonomic? It fits in well with these changes and would be useful to folks trying to refactor their related code.

@alice-i-cecile alice-i-cecile added the C-Usability A simple quality-of-life change that makes Bevy easier to use label Mar 20, 2021
@mockersf
Copy link
Member

the new api looks nice 👍

@wilk10
Copy link
Contributor

wilk10 commented Mar 22, 2021

i like the new API! thanks a lot for that.

however:

  • entity: Does... something? It's not documented, but I think it sets the current entity to use with the various EntityCommands
  • id: Seems to be the new replacement for current_entity?

i do agree with the confusion. i feel that they should contain a verb (eg: get_id) so that they consistent with being commands?

@cart
Copy link
Member Author

cart commented Mar 22, 2021

Is it worth solving #792 quickly before 0.5 to make this API really ergonomic? It fits in well with these changes and would be useful to folks trying to refactor their related code.

I'd prefer not to. Adding more features than we already are feels like to much risk at this point. Bundle merging also feels like a pretty superficial change from a user perspective (and non breaking). Folks are free to explore this and we can make a call when the code prior to release if the in front of us, but I think it would be a stretch.

i do agree with the confusion. i feel that they should contain a verb (eg: get_id) so that they consistent with being commands?

get_id() isn't a command, its a normal "getter". That means it should be in the x() form instead of get_x().

I do think the naming of world.entity(e1), commands.entity(e1), and world.entity_mut(e1) commands are worth discussing (especially in relationship to id()). These commands return "entity builder" structs for a specific entity (the same struct returned by spawn() and spawn_bundle()).

We could consider alternative names like world.entity_builder(e1) / world.entity_builder_mut(e1), but thats more of a mouth-full for a pretty common operation (especially when we account for the Option<EntityMut> variants: world.get_entity_builder_mut(e1)).

@alice-i-cecile
Copy link
Member

I'd prefer not to. Adding more features than we already are feels like to much risk at this point. Bundle merging also feels like a pretty superficial change from a user perspective (and non breaking). Folks are free to explore this and we can make a call when the code prior to release if the in front of us, but I think it would be a stretch.

I'm alright with this; we can explore it in another PR, probably after 0.5's release.

get_id() isn't a command, its a normal "getter". That means it should be in the x() form instead of get_x().

Your explanation was helpful, and I think that brevity is important to consider here. I think that good docstrings and examples should alleviate the confusion well enough here to stick with the shorter names.

@cart
Copy link
Member Author

cart commented Mar 22, 2021

Folks are free to explore this and we can make a call when the code prior to release if the in front of us, but I think it would be a stretch.

Wow what a dumpster fire of a sentence. I meant to say: "Folks are free to explore this and we can make a call prior to release if the code is in front of us".

Your explanation was helpful, and I think that brevity is important to consider here. I think that good docstrings and examples should alleviate the confusion well enough here to stick with the shorter names.

Cool cool. I'll add the docs.

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've read over the new docs and I think this is ready to merge. I'd prefer to do it sooner than later to reduce merge conflict headaches and give plugin authors a headstart on updating.

@rparrett
Copy link
Contributor

rparrett commented Mar 22, 2021

commands.entity(child).despawn();
commands.despawn_recursive(entity);

It seems like this inconsistency may have been overlooked, or maybe the hierarchy/state/alien cake examples didn't get updated.

@cart
Copy link
Member Author

cart commented Mar 23, 2021

It seems like this inconsistency may have been overlooked, or maybe the hierarchy/state/alien cake examples didn't get updated.

Yup it was overlooked. Fixed!

@cart
Copy link
Member Author

cart commented Mar 23, 2021

bors r+

bors bot pushed a commit that referenced this pull request Mar 23, 2021
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.
@bors bors bot changed the title Make Commands and World apis consistent [Merged by Bors] - Make Commands and World apis consistent Mar 23, 2021
@bors bors bot closed this Mar 23, 2021
siler added a commit to siler/bevy that referenced this pull request Mar 23, 2021
aevyrie added a commit to aevyrie/bevy_mod_raycast that referenced this pull request Mar 23, 2021
@recatek
Copy link
Contributor

recatek commented Mar 23, 2021

Little late to the party here, but I think insert would be initially confusing to me if I were just starting out, since it seems like I'm adding the component to a list. Maybe attach is a better metaphor for associating a component with an entity? I understand that with doesn't make sense in a world context.

aevyrie added a commit to aevyrie/bevy_mod_picking that referenced this pull request Mar 23, 2021
aevyrie added a commit to aevyrie/bevy_mod_bounding that referenced this pull request Mar 23, 2021
siler added a commit to siler/bevy that referenced this pull request Mar 24, 2021
bors bot pushed a commit that referenced this pull request Mar 26, 2021
The only API to add a parent/child relationship between existing entities is through commands, there is no easy way to do it from `World`. Manually inserting the components is not completely possible since `PreviousParent` has no public constructor.

This PR adds two methods to set entities as children of an `EntityMut`: `insert_children` and `push_children`. ~~The API is similar to the one on `Commands`, except that the parent is the `EntityMut`.~~ The API is the same as in #1703.
However, the `Parent` and `Children` components are defined in `bevy_transform` which depends on `bevy_ecs`, while `EntityMut` is defined in `bevy_ecs`, so the methods are added to the `BuildWorldChildren` trait instead.
If #1545 is merged this should be fixed too.

I'm aware cart was experimenting with entity hierarchies, but unless it's a coming soon this PR would be useful to have meanwhile.

Co-authored-by: Carter Anderson <mcanders1@gmail.com>
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-Usability A simple quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Better API for Commands methods that modify components
6 participants