You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
this
Signal name
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.
The text was updated successfully, but these errors were encountered:
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:this
void*
data, it is no worse thansignal_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 abovesignal_type_t::name
or as a fallback the typeid.The text was updated successfully, but these errors were encountered: