Re: Why are signal names strings and not enums?

[Emmanuele Bassi <ebassi gmail com>]

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
speculate.

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

> 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.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]