// this system spawns entities with the Position and Velocity components
fn setup(mut world: WorldBuilder) {
world
.spawn((Position(0.0), Velocity(1.0),))
.spawn((Position(1.0), Velocity(2.0),));
}
When reading code, this feels more natural in concept.
I think the commands queue is an implementation detail, it should be contained in the world builder, and also insert resources by the world builder.
This could be a nice step towards good type-safe commands too. You could also have EntityBuilder, ChildBuilder (already exists), etc. which would remove the need for panics in some of the functions.
So we do already have a WorldBuilder type that performs build operations directly on the real World type. Its basically a mirror of the current Commands interface. We would be stomping on it with a rename, but given that Commands is used everywhere, I'd be willing to give it priority for the "better" name.
I do agree that Commands isn't exactly self-documenting. Most of the time its just used to queue up world changes, so something like WorldBuilder makes sense in that context. But I think its important to note that it isn't just for queuing up World changes. Its also for queuing up Resource changes. And in the future we might use it to queue up system/app changes too.
That being said, lets leave issue open for a bit because I think its definitely useful to discuss the names (and apis) we should use here. I'd love to hear your thoughts!
Then I can think of the following options:
Commands to Commander.Commands with AppBuilder, which can access all the entities, systems, resources and app itself.World to EntityStorage, current App to World.Just for discussing, maybe either of the options not worth the effert.
After thinking more, I convinced myself to against these options:
Commands and Commander make not so much difference.Res and Query we are decomposing App for ease of access.App is more appropriate.So "Commands' controls the World and everything surrounding it? Sounds like a Universe :stuck_out_tongue_winking_eye:
Yeah I _think_ I'm happy with the names as they are. I'll close this issue for now, but feel free to create new issues if you have new name ideas.
Most helpful comment
After thinking more, I convinced myself to against these options:
CommandsandCommandermake not so much difference.ResandQuerywe are decomposingAppfor ease of access.Appis more appropriate.