`connect_self()` is not available for engine classes

[ColinWttt]

Related to #1111

[Yarwin]

Invoking methods with self receiver is not possible for the engine classes.

If you want to use given instance of an engine declared class in a connection you can just move it into closure, doing something along the lines of:

            let mut node = Node::new_alloc();
            let mut renamed = node.signals().renamed();
            renamed.connect(move || godot_print!("{}", node));

---

Additionally, for now, "base" signals are not available for an user-defined classes, see: #1111 (comment).

Next plan: making signals in base classes accessible. At the moment, Gd<T>::signals() only returns signals from the class T itself, but it should be possible to connect/emit those in superclasses as well.

Currently connecting self to base signal can be done via the connect_obj:

            obj.clone()
                .upcast::<BaseButton>()
                .signals()
                .pressed()
                .connect_obj(&obj, MyObj::method);

[ColinWttt]

Invoking methods with self receiver is not possible for the engine classes.

Thank you! I honestly hadn’t thought about this point. When I saw PR#1111, “it’s the exact same API as before” and noticed that connect_self was missing, I submitted the issue.

If you want to use given instance of an engine declared class in a connection you can just move it into closure, doing something along the lines of:

I used a closure, moving self.to_gd() into it, and it runs correctly.

        let mut gd = self.to_gd();
        tween
            .signals()
            .finished()
            .connect(move || gd.set_process(true));

equivalent to

         tween.tween_callback(
             &self
                 .base_mut()
                 .callable("set_process")
                 .bind(&[true.to_variant()]),

[Bromeon]

Thank you! I honestly hadn’t thought about this point. When I saw PR#1111, “it’s the exact same API as before” and noticed that connect_self was missing, I submitted the issue.

It's a fair point, and I agree it's not intuitive that this one is missing.

Generally, signal support is added incrementally, due to the magnitude of the topic:

• Initial support for #[signal] in Type-safe signals #1000
• Improvements to visibility in Explicit signal visibility #1075
• Initial support for engine-based signals in Type-safe signals for engine classes #1111
• QoL for engine-based signals
  • Access base signals from derived classes
  • Make user and engine signals behave as close as possible
• QoL for emission
  • AsArg support
• Disconnection
• Re-entrancy Re-entrant emitting of signals + script-virtual functions #916

So please don't assume because a PR was merged, everything should work out of the box 😉
This will continue to be the case for some time. Contributions are of course welcome, too!

---

Regarding connect_self in particular: from my proposed solutions in #1111 (comment), the Deref one would likely not support this on its own, because a signal collection of a base class Node will only know about Node, whereas self would be a user-defined derived class.

So, for user-defined signal collections, we might need to duplicate all base signals, or introduce a generic parameter that stores the derived class.

For engine-defined classes themselves, connect_self won't be necessary, since the user will only have outside references to the object (as Gd pointers), not within an impl block:

let node: Gd<Node> = ...; // actual Node, not derived
node.signals().some_signal().connect(...);