bevyengine
Multiple types have conflicting/confusing type names.
Bevy has reused the same conceptual names for multiple types across things within bevy. Ie Query is used by bevy_ecs and cosmic_text, Handle in Bevy_asset and bevy_log, etc This creates confusion especially for autocomplete tooling like in vscode where the conflict leads to confusing errors that a normal person will not understand as syntactically they have done everything correctly.
Bevy should reserve the key conceptual ideas such as Query, Param, System, Handle, etc and any reuse should be name scoped, ex cosmic_text Query renamed to CosmicQuery etc
Checklist of conflicts (Ongoing) Please comment any additional items for renaming
- [ ] Query: Bevy_ecs > cosmic_text
- [ ] Handle: Bevy_asset > Bevy_log
I believe best route would be to go through and search common concepts. If a conflict is found favor the bevy local name, so ecs Query stays and rename cosmic_text Query to CosmicTextQuery or CosmicQuery. If a conflict is between bevy crates, such as Handle in asset vs log, we should favor the one thats more important to development, so Handle should stay in asset and in log renamed to LogHandle.
I think renaming with their scope like this is the simplest solution to it.
Yep, I'd love a checklist in this issue of all of the items that need renaming. We should then tackle them one item at a time in separate PRs so they don't get stalled out.
I think re-exporting cosmic text in its entirety should be reconsidered. Imo it should largely be an implementation detail, except for advanced use cases. People in that position can just add a top level dependency to their project.
would that go the same for the encase re-exports?
Yes please. Rendering is also interested in removing encase as a dependency completely IIRC, so that's a fine step forward.
Bevy API docs / all items -> cut & paste into VSCode, Remove all lines which mention prelude::, Regex delete all module names, Sort lines, Run uniq -d, This yields a list of about 300 names, most of which are false positives. However, a few interesting ones are: Access, Anchor, Builder, Buffer, Cursor, Color, Command, Direction, Rect, Transform
(Most of these are dups from cosmic, although Access and Builder are not.)
I've been annoyed at Direction in the past, it's defined in cosmic_text::rustybuzz and bevy_ecs::schedule::graph
From Discord conversation.
This weekend I had bevy::ecs::world::Entry and both bevy::platform::collections::{hash_map::Entry, hash_set::Entry} in the scope. The latter two are from hasbrown but the first could have a different name, like ComponentEntry.
bevy_render::camera::ScalingMode and bevy_sprite::ScalingMode (the latter also happens to be in the prelude).
Hi, I investigated the remaining items in the checklist. Here's what I found:
-
bevy_log Handle - I checked the entire
bevy_logcrate, there's no Handle re-export. Not sure where this came from. -
bevy_assets::Entry - This is a private enum (no
pub), so it's not exposed in the API at all. Can't cause autocomplete issues. -
ScalingMode - Already solved by #21100 .
