-
-
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
Rename WorldQueryData
& WorldQueryFilter
to QueryData
& QueryFilter
#10779
Rename WorldQueryData
& WorldQueryFilter
to QueryData
& QueryFilter
#10779
Conversation
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
@ItsDoot @james-j-obrien review please :D |
@taizu-jin great PR description <3 Thanks for tackling this. |
So the "fix" 25b9d7d for missing_deref test was actually an opposite. Is there a reason why my test run had a different output there and I could fix that instead or I should've just ignored it because I didn't touch that part of the code? |
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'm a fan. The World
prefix always looked odd to me (it's not used anywhere else) and seemed like a way to avoid conflicting with the Query
type. Now that it's not a problem I see no reason not to do this.
@@ -29,7 +29,7 @@ mod field_attr_keywords { | |||
syn::custom_keyword!(ignore); | |||
} | |||
|
|||
pub static WORLD_QUERY_DATA_ATTRIBUTE_NAME: &str = "world_query_data"; | |||
pub static WORLD_QUERY_DATA_ATTRIBUTE_NAME: &str = "query_data"; |
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.
Perhaps remove WORLD
here as well?
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 was contemplating this as well. How about derive_world_query_filter
, derive_world_query_filter_impl
fns and their helper structs? Does it make sense to also rename the source file as well?
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.
Imo it doesn't make sense to leave traces of the old naming that might mislead future contributors, but in the end these internal names/filenames aren't going to affect users so it's not a huge deal.
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.
Gotcha, I'm leaning on cleaning it up completely. Do you mind if I re-request for a review after the changes?
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.
Looks good as-is, as long as James' concerns are satisfied. All the suggestions I list here are just suggestions and not required for my approval.
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 think WorldQueryDataFilter
and WorldQueryDataAttributes
should be changed. They are private, but still worth changing for consistency.
Also, module names and their respective files should be adapted too (e.g. world_query_data.rs
→ query_data.rs
)
5dc8686
to
9e09aec
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.
Review was tedious but straightforward. I think we can proceed.
…10782) # Objective Since #10776 split `WorldQuery` to `WorldQueryData` and `WorldQueryFilter`, it should be clear that the query is actually composed of two parts. It is not factually correct to call "query" only the data part. Therefore I suggest to rename the `Q` parameter to `D` in `Query` and related items. As far as I know, there shouldn't be breaking changes from renaming generic type parameters. ## Solution I used a combination of rust-analyzer go to reference and `Ctrl-F`ing various patterns to catch as many cases as possible. Hopefully I got them all. Feel free to check if you're concerned of me having missed some. ## Notes This and #10779 have many lines in common, so merging one will cause a lot of merge conflicts to the other. --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective > Can anyone explain to me the reasoning of renaming all the types named Query to Data. I'm talking about this PR #10779 It doesn't make sense to me that a bunch of types that are used to run queries aren't named Query anymore. Like ViewQuery on the ViewNode is the type of the Query. I don't really understand the point of the rename, it just seems like it hides the fact that a query will run based on those types. [@IceSentry](https://discord.com/channels/691052431525675048/692572690833473578/1184946251431694387) ## Solution Revert several renames in #10779. ## Changelog - `ViewNode::ViewData` is now `ViewNode::ViewQuery` again. ## Migration Guide - This PR amends the migration guide in #10779 --------- Co-authored-by: atlas dostal <[email protected]>
Rename
WorldQueryData
&WorldQueryFilter
toQueryData
&QueryFilter
Fixes #10776
Solution
Traits
WorldQueryData
&WorldQueryFilter
were renamed toQueryData
andQueryFilter
, respectively. Related Trait types were also renamed.Changelog
WorldQueryData
has been renamed toQueryData
. Derive macro'sQueryData
attributeworld_query_data
has been renamed toquery_data
.WorldQueryFilter
has been renamed toQueryFilter
. Derive macro'sQueryFilter
attributeworld_query_filter
has been renamed toquery_filter
.ExtractComponent
typeQuery
has been renamed toData
.GetBatchData
typesQuery
&QueryFilter
has been renamed toData
&Filter
, respectively.ExtractInstance
typeQuery
has been renamed toData
.ViewNode
typeViewQuery
has been renamed toViewData
.RenderCommand
typesViewWorldQuery
&ItemWorldQuery
has been renamed toViewData
&ItemData
, respectively.Migration Guide
Note: if merged before 0.13 is released, this should instead modify the migration guide of #10776 with the updated names.
WorldQueryData
&WorldQueryFilter
trait usages toQueryData
&QueryFilter
and their respective derive macro attributesworld_query_data
&world_query_filter
toquery_data
&query_filter
.ExtractComponent
typeQuery
toData
.GetBatchData
typeQuery
toData
.ExtractInstance
typeQuery
toData
.ViewNode
typeViewQuery
toViewData
'RenderCommand
typesViewWorldQuery
&ItemWorldQuery
toViewData
&ItemData
, respectively.