-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Read-only queries cannot be issued on a read-only &World #3774
Comments
Related to #2192: the In many cases, it is not feasible to require that the users manually handle state caching. We may be able to cache the system state, and then look it up by type signature later? That optimization should definitely wait until after Stageless though. |
Personally, I don't think allowing query initialization from &World is a good idea. This encourages losing state which is both a minor perf footgun and a major correctness footgun in case
I'd like to see some examples here, because I personally think it's fairly easy. Furthermore, this conflicts with other potential plans, namely registration hooks. |
Hmm, I do see your point there with |
Yes, but a footgun already existing isn't an excuse to make it more prevalent. We should encourage storing this state, not discourage it. |
Currently, However, at first glance I think I agree with Nile that this may not be necessary to include. You should be able to do read-only queries by just adding a |
Here's a use case I'm running into from Nannou: We wrap an A Nannou application is implemented as a series of lifecycle functions, some of which accept I'm solving this via interior mutability right now, which is fine for us right now, but is still a little annoying. |
Personally I find this feature useful if you use bevy ecs internally and expose as traditional Works well as far you can clone/copy your results. As soon you start to return references, the API usage become a mess. On the example: struct Api { world: World, .. }
impl Api {
fn update(&mut self, delta_time: f32)
fn get_player(&self) -> &Player;
fn get_grid(&self) -> &Grid<T>
} If |
Yup, this is exactly the same issue we are running into. |
For my usecases, I have found that I would really like (need) something like
which is able to use immutable world to return an entity as long as only a single entity has the component (T). Then, the following line of code [common usecase] could be like
I need this and I dont think it would be 'illegal' , since you can already do this with a resource. This essentially allows me to use a singleton component like a resource that is tied to an entity. The fact that I can only query for entities based on components with mut world right now is not enough for me. I dont have access to mut world for what I am doing. [ i want to be able to find (read) those ui nodes ( by singleton component) inside of World access for all of my fancy reactive components (like my component that sets UI visibility based on a custom struct that implements a trait function that takes in World and outputs the visibility state for each frame -- allowing for declarative computation of visibility ) ] I can understand why world.query needs mut world but if you are expecting to only do a .single() on the query, it for sure should not need mut world but this isnt an option at the moment . This is a more constrained 'ask' compared to the OP suggestion and so may be safer to implement..? but still useful. |
It should be possible to make a version of |
Why is that the case for |
Problem
Given a
&World
, I cannot issue a query that only reads from the world.There are two possible methods on
World
for this:query
,query_filtered
, plusSystemState::new()
. All of them require&mut World
, as they could provide mutating type parameters.Proposed Solutions
Quick-and-dirty
Make read-only variants of all three methods.
Ergonomic
Add a
system_state
andread_only_system_state
method toWorld
, which generates aSystemState
and then immediately calls.get_mut
/.get
on it.This allows users to do things like:
The text was updated successfully, but these errors were encountered: