Reintroduce get_
prefixes (revert #477) by Bromeon · Pull Request #487 · godot-rust/gdext (original) (raw)
This reverts commit d36a144 from pull request #477.
Prepares some logic for overriding const-qualification, without yet enabling it.
Rationale:
- Godot has non-typical APIs for Rust, following tradititional OOP style with lots of getters/setters.
- My idea was that porting GDScript's property access to Rust might be more natural:
node.position
becomesnode.position()
. However, Godot's naming is much less consistent than I was initially assuming:size_flags_horizontal
property has{get/set}_h_size_flags
accessorsNode.get_path()
andNode.get_parent()
look like they should have properties, but don't; so.path()
and.parent()
would be a "wrong mapping".Node
bool propertyunique_name_in_owner
has{get/is}_unique_name_in_owner
.
However,{get/set}_scene_instance_load_placeholder
methods also return bool but have no property. So mapping would yieldis_unique_name_in_owner
andscene_instance_placeholder
. Stripping the "is_" for consistency would be confusing:unique_name_in_owner
sounds like it returns the name.
- Some
get_
methods take parameters.MeshDataTool
hasget_vertex_count()
andget_vertex_color(index)
-- the former would lose its prefix but the latter would not since it's not strictly a "getter" in the Rust sense.- It could even happen that such parameters have defaults, in which case a single method would act as both getter and getter-with-param. It's unclear how we'd map it under our
_ex
model.
- Since some verbs are simultaneously nouns, this makes APIs slightly harder to understand in some cases.
scale()
queue()
(already causing a conflict)process_delta_time()
format()
modulate()
- Exceptions and rules that depend on presence of properties make backwards compatibility harder.
- if a new property is added, it might not map to the way how Rust maps an existing
get_
method - if Godot has a method
get_format()
which we map toformat()
, and then Godot adds another methodformat()
later, we have a conflict
- if a new property is added, it might not map to the way how Rust maps an existing
- Getters are harder to discover.
- partly due to issues above (intermixing with "doer" style methods/verbs)
- there is no more
get_
autocompletion in IDEs
TLDR: There needs to be a complex ruleset, with lots of edge cases. In the end we may come up with something that looks nice and somewhat consistent when looking at the Rust part, but it will be too distant from the GDScript API, making porting between the two harder. We should probably embrace imperfections in the Godot API rather than trying to fight them.