-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Remove WorldCell #3939
Remove WorldCell #3939
Conversation
@bevyengine/ecs-team; this is fundamentally a design decision. RFC #42 seems fairly doomed (a decision I support), but if it's doomed we should close it and remove the half-working
|
Ah, my search for |
Pretty sure they can all be replaced with SystemState or resource_scope. |
I agree. This is a risky pattern, and non-trivial uses of this are likely to lead to complex runtime panics whenever surrounding code is changed. IMO the ideas discussed in #2192 are a much better way to accomplish the same goals. |
It's a bit frustrating not to have a better solution for #2192 yet; the extremely complex system state constructed in Overall, that refactor was quite painless, even for extremely complex uses of |
I personally think requiring &mut World and adding hooks would be a better way to support this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the idea, but the winit runner can be done better imo.
# Objective - In the large majority of cases, users were calling `.unwrap()` immediately after `.get_resource`. - Attempting to add more helpful error messages here resulted in endless manual boilerplate (see #3899 and the linked PRs). ## Solution - Add an infallible variant named `.resource` and so on. - Use these infallible variants over `.get_resource().unwrap()` across the code base. ## Notes I did not provide equivalent methods on `WorldCell`, in favor of removing it entirely in #3939. ## Migration Guide Infallible variants of `.get_resource` have been added that implicitly panic, rather than needing to be unwrapped. Replace `world.get_resource::<Foo>().unwrap()` with `world.resource::<Foo>()`. ## Impact - `.unwrap` search results before: 1084 - `.unwrap` search results after: 942 - internal `unwrap_or_else` calls added: 4 - trivial unwrap calls removed from tests and code: 146 - uses of the new `try_get_resource` API: 11 - percentage of the time the unwrapping API was used internally: 93%
Please ping me when this is ready to merge, assuming it happens after #3974. I want to double check that everything still behaves as expected. 🙂 |
Co-authored-by: Aevyrie <aevyrie@gmail.com>
Will do! From my perspective, this is ready-to-merge; it's just waiting on a final decision from Cart. |
Got it! We'll just have to be mindful if/when this and #3974 are merged that we don't accidentally break anything in the merging process. We don't have an effective way to automatically test the window updating just yet. |
- In the large majority of cases, users were calling `.unwrap()` immediately after `.get_resource`. - Attempting to add more helpful error messages here resulted in endless manual boilerplate (see bevyengine#3899 and the linked PRs). - Add an infallible variant named `.resource` and so on. - Use these infallible variants over `.get_resource().unwrap()` across the code base. I did not provide equivalent methods on `WorldCell`, in favor of removing it entirely in bevyengine#3939. Infallible variants of `.get_resource` have been added that implicitly panic, rather than needing to be unwrapped. Replace `world.get_resource::<Foo>().unwrap()` with `world.resource::<Foo>()`. - `.unwrap` search results before: 1084 - `.unwrap` search results after: 942 - internal `unwrap_or_else` calls added: 4 - trivial unwrap calls removed from tests and code: 146 - uses of the new `try_get_resource` API: 11 - percentage of the time the unwrapping API was used internally: 93%
Closing in favor of the dramatically less controversial #5109. I still think this should be done, but the code-quality changes should be ported over ASAP anyways. |
Our internal uses of |
Objective
WorldCell
is not fully featured: see Expand WorldCell to support queries #1555.Cell
(a runtime borrow-checked API to split borrows arbitrarily).Solution
WorldCell
completely, rather than keeping a half-working implementation around.SystemState
orresource_scope
as needed.World
.Notes
In the places where this was used:
SystemState
FromWorld
impls)winit_runner_with
) was straightforward but rather verbose, and reflective of generally not-great code quality (it should be reusable but isn't, and is rather unstructured)