Add an Entry api to EntityWorldMut.
#10650
Conversation
…ifetime transmutation with questionable safety, question for the future
…insert (more questionable transmutation)
…ed (otherwise we should be using `or_insert`)
|
Meets my needs. Minor nit on doc comment. |
|
Could we also get those for commands? |
Since commands are asynchronous, this would be more difficult: you can't insert a component and get back the same component instance in the same tick (I think). |
Should be possible when we introduce a EntityEntryCommands thing like EntityCommands which you can call |
alice-i-cecile
added
A-ECS
Co-authored-by: Pascal Hertleif <[email protected]>
Agreed, but let's leave that for another PR :) |
| /// assert_eq!(world.query::<&Comp>().single(&world).0, 0); | ||
| /// ``` | ||
| #[inline] | ||
| pub fn or_default(self) -> Mut<'a, T> { |
There was a problem hiding this comment.
Might be nice to make both a FromReflect and FromWorld equivalent, but those can wait.
alice-i-cecile
added
the
D-Complex
…plaining how it must be occupied before being created (it has private fields so this shouldn't be a problem for user code).
…comments explaining why it should never panic.
|
Replacing |
alice-i-cecile
added
the
S-Ready-For-Final-Review
# Objective Adds `.entry` to `EntityWorldMut` with `Entry`, `OccupiedEntry` and `VacantEntry` for easier in-situ modification, based on `HashMap.entry`. Fixes bevyengine#10635 ## Solution This adds the `entry` method to `EntityWorldMut` which returns an `Entry`. This is an enum of `OccupiedEntry` and `VacantEntry` and has the methods `and_modify`, `insert_entry`, `or_insert`, `or_insert_with` and `or_default`. The only difference between `OccupiedEntry` and `VacantEntry` is the type, they are both a mutable reference to the `EntityWorldMut` and a marker for the component type, `HashMap` also stores things to make it quicker to access the data in `OccupiedEntry` but I wasn't sure if we had anything it would be logical to store to make accessing/modifying the component faster? As such, the differences are that `OccupiedEntry` assumes the entity has the component (because nothing else can have an `EntityWorldMut` so it can't be changed outside the entry api) and has different methods. All the methods are based very closely off `hashbrown::HashMap` (because its easier to read the source of) with a couple of quirks like `OccupiedEntry.insert` doesn't return the old value because we don't appear to have an api for mem::replacing components. --- ## Changelog - Added a new function `EntityWorldMut.entry` which returns an `Entry`, allowing easier in-situ modification of a component. --------- Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: Pascal Hertleif <[email protected]>
Objective
Adds
.entrytoEntityWorldMutwithEntry,OccupiedEntryandVacantEntryfor easier in-situ modification, based onHashMap.entry.Fixes #10635
Solution
This adds the
entrymethod toEntityWorldMutwhich returns anEntry. This is an enum ofOccupiedEntryandVacantEntryand has the methodsand_modify,insert_entry,or_insert,or_insert_withandor_default. The only difference betweenOccupiedEntryandVacantEntryis the type, they are both a mutable reference to theEntityWorldMutand a marker for the component type,HashMapalso stores things to make it quicker to access the data inOccupiedEntrybut I wasn't sure if we had anything it would be logical to store to make accessing/modifying the component faster? As such, the differences are thatOccupiedEntryassumes the entity has the component (because nothing else can have anEntityWorldMutso it can't be changed outside the entry api) and has different methods.All the methods are based very closely off
hashbrown::HashMap(because its easier to read the source of) with a couple of quirks likeOccupiedEntry.insertdoesn't return the old value because we don't appear to have an api for mem::replacing components.Changelog
EntityWorldMut.entrywhich returns anEntry, allowing easier in-situ modification of a component.