Description
Describe the project you are working on
Nodes with setters on exported variables which cause effects on children nodes. to avoid errors, if the node isn't ready yet, the setters either await ready or return before messing with the children.
Describe the problem or limitation you are having in your project
godotengine/godot#75751 added is_ready to the Node class, but it had to be exposed as is_node_ready() because it collides with RichTextLabel's function with the same name.
is_node_ready(), which my code already uses in several places, is more cumbersome to type and read than simply is_ready().
Meanwhile, I've never used RichTextLabel's is_ready function, and conceptually it's not as attached to the name being specifically "is ready" as the Node function is.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Change the Node function's name to is_ready, and the RichTextLabel's function to something else.
I'm not familiar with the RichTextLabel class so I don't personally know or care what name would be appropiate. Akien suggested is_done_processing.
This change would break compatibility as it renames two functions. I'm making the suggestion now so it's there for when that can happen.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I think all it'd take is renaming the bound method names for both Node::is_ready() in node.cpp and RichTextLabel::is_ready() in rich_text_label.cpp.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It'll be used just as often as the function is used.
You could add func is_ready(): return is_node_ready() in every single node script that you want to use it in, but manual renames like that aren't worth it.
Is there a reason why this should be core and not an add-on in the asset library?
It's a rename. Even if it was possible, a compatibility-breaking addon could break other addons.