-
-
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
Reorganize system modules #8419
Conversation
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'd like to break up the top level mod.rs a great deal further, but this is incrementally better.
Is there anything specific you'd like to be moved into different modules? As of this PR, |
I think the |
I can split it out if you'd prefer, but I don't think it's necessary. It'd be easy to move that module into a different file but I don't think there's much reason to -- that module isn't doing anything complicated or novel, it's just a relatively short list of trivial functions, similar to Also, this may not go anywhere, but note that I've been working on a PR that would deprecate the |
Sounds good; I'm fine to leave it alone. |
Objective
Follow-up to #8377.
As the system module has been refactored, there are many types that no longer make sense to live in the files that they do:
IntoSystem
trait is infunction_system.rs
, even though this trait is relevant to all kinds of systems. Same for theIn<T>
type.PipeSystem
is now just an implementation ofCombinatorSystem
, sosystem_piping.rs
no longer needs its own file.Solution
IntoSystem
,In<T>
, and system piping combinators & tests into the top-levelmod.rs
file forbevy_ecs::system
.PipeSystem
intocombinator.rs
.