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

Rework signal_connection_t #1307

Closed
ammen99 opened this issue Oct 11, 2021 · 0 comments · Fixed by #1495
Closed

Rework signal_connection_t #1307

ammen99 opened this issue Oct 11, 2021 · 0 comments · Fixed by #1495
Labels
api-breaking API breaking change
Milestone

Comments

@ammen99
Copy link
Member

ammen99 commented Oct 11, 2021

signal_connection_t and signals as a whole turns out quite unpleasant to work with in language bindings (wflua being an example, my own attempts at C bindings as well). We also have the signal names spread across many files, and completely unnecessary type casts everywhere. A better design for signals would be:

  • signal_provider_t emits the signal together with:
    1. this
    2. Signal name
    3. Untyped void* data, it is no worse than signal_data_t*, the latter doesn't have RTTI anyway since it doesn't declare any virtual methods.
  • signal_connection_t works as it does now, with the additional parameters from above
  • A new helpers for typed signals which are 99% of all signals:
    • Helpers use templates to specialize to various signal types
    • Signal name is either signal_type_t::name or as a fallback the typeid.
    • Signal handler also knows the type (so no need to specify the signal name), and auto-casts the signal data to the correct type.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-breaking API breaking change
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant