Skip to content
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

Draft - Single Shot Connection #21

Closed
LeonMatthesKDAB opened this issue Feb 2, 2022 · 4 comments
Closed

Draft - Single Shot Connection #21

LeonMatthesKDAB opened this issue Feb 2, 2022 · 4 comments
Labels
enhancement New feature or request question Further information is requested
Projects

Comments

@LeonMatthesKDAB
Copy link
Contributor

LeonMatthesKDAB commented Feb 2, 2022

A single shot connection could possibly be implemented by creating a binding that captures its own ConnectionHandle and disconnects it when the signal is emitted.

Open question: How to capture the ConnectionHandle in the slot itself?

@LeonMatthesKDAB LeonMatthesKDAB added this to Backlog in KDBindings Feb 2, 2022
@LeonMatthesKDAB LeonMatthesKDAB added enhancement New feature or request question Further information is requested labels Apr 1, 2022
@phyBrackets
Copy link

phyBrackets commented Sep 28, 2023

I'm a bit confused about this, don't we need a special method for single shot connection, like singleShotConnect ? that gets disconnected after emit, which could be easily implemented just by having a set flag isSingleShot in singleShotConnect and each time when emit gets called, it should check that emit was on a single shot connection and if that's the case immediately disconnects it? Don't need to get around connection handle.

@LeonMatthesKDAB
Copy link
Contributor Author

LeonMatthesKDAB commented Oct 4, 2023

That should work as well. I was just thinking that something like this should maybe be possible:

mySignal.connect([](const auto &handle) {
    // do thing
    handle.disconnect();
});

More of a thought experiment than anything substantial. An approach like that wouldn't need another connect function and seems kind of elegantly recursive almost. It would even allow you to block the connect after it's first emitted, instead of disconnecting. It could then be unblocked again without having to reconnect. Might be useful for rate-limiting 🤔

But it's also incompatible with the current connect function I think, so don't know if it's worth continuing down.

Introducing a singleshotConnect function definitely works as well, so that's the more likely route to go down.
Though something like connectReflective would be cool, that allows you to reach your own ConnectionHandle...
That might run into weird lifetime issues though, where a lambda is deleted while in use, which could get quite hairy...

Anyhow, some food for thought.

@LeonMatthesKDAB
Copy link
Contributor Author

The basics of reflective connections were layed out in #23, so we may want to revisit this idea :)

@LeonMatthesKDAB
Copy link
Contributor Author

Complete as of #70

KDBindings automation moved this from Backlog to Done Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
Development

No branches or pull requests

2 participants