Make `World` interface more convenient.

[rj00a]

• World::get should take a Q: ReadOnlyQuery instead of a Component.
• World::get_mut should take a Q: Query instead of a Component.
  • One problem is that we need to check for self-aliasing since (&mut A, &mut A) is a valid query. Checking for self-aliasing is somewhat expensive, and we wouldn't want to pay for that on every call. We could store a HashSet<TypeId> in the World to cache queries that are known not to self-alias. We can also optimize this for simple queries like &mut C to skip going to the cache.
• There should be single and single_mut methods for accessing singletons.
• There should be a World::iter method for iterating over a Q: ReadOnlyQuery.
• There should be a World::iter_mut method for iterating over a Q: Query. It will need to use the same self-alias checking as above.

The iter methods should not construct a cached query on every invocation.

[andrewgazelka]

What are your thoughts on having an alternative spawn method?

let entity_id = world.spawn();
world.insert(entity_id, ComponentA);
world.insert(entity_id, ComponentB);

could potentially be cleaner if written like

let entity_id = world.spawn_entity((ComponentA, ComponentB));

I'm not set on the spawn_entity name. There may be a better name. This should clean up the code, though. Perhaps this could also help O(n^2) problem mentioned in #5 in certain situations (although not good perm solution)

[rj00a]

That seems reasonable. We could just change spawn to behave like spawn_entity and require writing .spawn(()) if the old behavior is needed. We will want to do the same for Sender too.

I don't think it would immediately help with #5 though since we want it to be semantically equivalent to inserting the components individually. We still need command batching to make that efficient.

[andrewgazelka]

That seems reasonable. We could just change spawn to behave like spawn_entity and require writing .spawn(()) if the old behavior is needed. We will want to do the same for Sender too.

I don't think it would immediately help with #5 though since we want it to be semantically equivalent to inserting the components individually. We still need command batching to make that efficient.

ok cool. I think bevy by default (I might be very wrong) lets one spawn an entity with multiple components in one call so I am for a new spawn impl

[andrewgazelka]

Hey @rj00a have you been working on this? I'm very interested in the new spawn impl but I do not want to work on it if you are working on this :) and it would really benefit me.

[rj00a]

Hey @rj00a have you been working on this? I'm very interested in the new spawn impl but I do not want to work on it if you are working on this :) and it would really benefit me.

Going to try to get this and #59 done today :)