-
Notifications
You must be signed in to change notification settings - Fork 5
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
Prefer System Tuples, replace in_schedule, aggressive add_systems merging #10
Prefer System Tuples, replace in_schedule, aggressive add_systems merging #10
Conversation
2c9526f
to
50fa6f5
Compare
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 like add_systems_to. The double-parantheses and tuple abuse are a bit naff, but we'll need a builder style escape hatch anyways to account for arbitrary lengths so people who prefer it can use that instead.
add_system should still exist, but I do like grouping systems by default.
Tuple nesting seems both natural and good.
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.
LGTM.
I'd prefer if each sentence was on its own line to be consistent with the rest of the doc (makes it easier for GitHub to diff changes).
Cool cool. I made sure to call out
Yeah I think I'm on that team too (easier migration path, reads better for single systems). I intentionally took it "too far", just too see how it made us feel 😄
I haven't sorted out my feelings on this style, but I'm happy to align with it here for consistency. |
It should render the same. I just mean in the file. If you have two sentences on different lines, the generated Markdown will still show them on the same line.
They would only be rendered on different lines when there was an additional newline in between them, or if there were two spaces after the first sentence. Not what I wanted. Having each sentence on a different line of the file has made it a little easier for us to view the changes in the diff view. Though I guess if you're going to merge the RFC and we never edit this document again, then it doesn't really matter. |
(but leave the door open for optional macros)
50fa6f5
to
47b900e
Compare
Yeah I'm not worried about that. My only hangup is "forcing people into this style as a matter of policy". Idk if the churn there is worth the diff-reviewability wins. But thats a conversation we should have later. Happy to align with the style in the current RFC. Consistency is the only reason I need. |
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.
Renaming SystemLabel
-> SystemSet
will clear up a lot of potential confusion, I think. Removing some macros is nice, too.
Followup to #9 (which should be merged first)
This pr includes a number of small UX tweaks (some of which will be controversial), each split up into its own commit. I personally like where it landed, but every commit is negotiable. The last couple are especially controversial I think 😄