Re: Why are signal names strings and not enums?

On 6 October 2017 at 12:23, Stefan Salewski <mail ssalewski de> wrote:
We are using code like

   g_signal_connect(G_OBJECT(btn), "clicked",
      G_CALLBACK(gtk_main_quit), G_OBJECT(window));

  g_signal_connect(G_OBJECT(window), "destroy",
      G_CALLBACK(gtk_main_quit), NULL);

Why strings and not enums for clicked and destroy parameter?

Signal names were encoded as strings in the very beginning, and even
if there was a reason, it's now lost in the mists of time. We can but

One of the reasons is that signal details with enumerations are
impossible, as you cannot have a compact "notify::foo" signal

Well, strings have the disadvantage that undefined signal names are not
discovered during compile process.

You cannot discover signals at compile time, since they are added at
run time anyway.

The only way to have them discoverable at compile time with
enumerations would be to have a public enumeration type with the names
of all signals.

Additionally, enumerations are just integers, so the API would need to be:

  g_signal_connect (gpointer instance, int signal_id, ...)

which doesn't give you anything in terms of type safety at compile time.


[@] ebassi []

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]