-
-
Notifications
You must be signed in to change notification settings - Fork 198
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
Allow custom receivers in virtual methods #359
Comments
This could also mitigate #302 to an extent |
It can be argued that since bad runtime borrows are a common source of confusion, having an explicit fn ready(this: Gd<Self>) {
let this = this.bind_mut();
...
} would be clearer. But I don't fully like this, as it makes code less ergonomic and punishes all the common cases like I was also considering that |
We could just have it desugar to something like impl NodeVirtual for MyClass {
fn ready(this: Gd<Self>) {
Self::ready(this.bind())
}
}
impl MyClass {
fn ready(&self) {
// code
}
} Idk the exact syntax to make the name resolution work properly here but yeah. |
Regarding #338, I'm not sure if this would allow you to workaround the situation described therein. fn ready(this: Gd<Self>) {
this.bind_mut().add_child(...); // Mutable borrow of Gd<Self>
}
fn on_notification(this: Gd<Self>, n: ...) {
// do something with this, either bind / bind_mut -> panic due to aliasing
} on_notification would still be required to not touch this, as far as I can see |
Shouldn't it work if fn ready(this: Gd<Self>) {
this.upcast::<Node>().add_child(...); // Uses DerefMut, since Node is an engine class
}
fn on_notification(this: Gd<Self>, n: ...) {
// do something with this, either bind / bind_mut -> no panic?
} |
Great observation! In fact, that's one of the main motivations for #131. I'll probably implement that soon. |
Maybe the user can optionally choose to impl #[godot_api]
impl NodeVirtual for Gd<MyClass> {
fn ready(self) {
...
}
} |
Interesting idea, but that would mean:
|
It doesn't address the case of existing interfaces, but I was able to throw together #396 to allow user defined methods to take |
Just ran into this issue when I tried to test #883 #[derive(GodotClass)]
#[class(editor_plugin, tool, init, base=EditorPlugin)]
pub struct MySuperEditorPlugin {}
#[godot_api]
impl IEditorPlugin for MySuperEditorPlugin {
fn enter_tree(&mut self) {
let mut editor_button = Button::new_alloc();
editor_button.connect(
"pressed".into(),
Callable::from_object_method(
self, // ???????
"editor_button_pressed_event",
),
);
}
} So I have to make an (unnecessary?) "inner" object just to handle signals |
Currently most virtual methods take
&mut self
as the receiver, this can be problematic if you want to call multiple virtual methods at once from godot. We could loosen this restriction.One way to do this would be to make all virtual methods take
Gd<Self>
instead as the first argument, and have the#[godot_api]
macro rewrite the function slightly to take the appropriate reference.This would also allow you to workaround #338. Especially if we allow the user to specify
Gd<Self>
as the receiver.The text was updated successfully, but these errors were encountered: